Flock 2016: my notes
Last week we were at Flock 2016 which was held in Krakow, Poland. Awesome event, lots of news, great people, plenty of conversations and fun.
Here is a list of my notes:
…Handling secrets when building docker images is easy
So you wanna build a docker image. And you need to fetch your application sources from git. Which is guarded by ssh. And you don’t want the ssh key to get leaked into the final image. Bummer.
Unless…
…Download manifests from Docker Hub
So we needed to fetch manifests of repositories from Docker Hub today. It’s not
that hard. 30 lines of python can do it. But at the same time, you need to read
docs with all the specs.
Simple way to check for race conditions
Today was a fun day. We were working on a piece of code which interacts with PostgreSQL database. One function was reading from database and based on the query result it inserted some data afterwards. The thing is that it wasn’t done in a transaction so I suspected there could be a race condition. But how to test such case? My requirements for such test were obvious: I wanna spam the server with streams of requests and check logs if the server is able to handle it.…
Automatic mounts with systemd
So I wanted to setup automatic mounting (read as autofs) with systemd, without using fstab.
Unfortunately, the man page didn’t have any examples so it wasn’t that easy to figure out. Luckily there is an excellent guide at RHCSA course [1].
Tl;dr
…Building docker images with two Dockerfiles
So I got asked about this topic after my DevConf 2016 talk: there is a solution available on internets which describes how one can use two dockerfiles to build an image. Whole article can be found here.
What I didn’t like about the solution is that the first image outputs whole
build artifact as a tarball to standard output. To me that’s a bit hacky. Since
docker 1.8 you can cp files and directories between containers and host.
Let’s try to do that!
All of this is because of build secrets. It may happen that you need to
authenticate with an external service when building a docker image. In order to
do that, you need to have a secret available during build. That’s a problem.
This key may leak into a final image (whether via docker history or will be
available directly in some layer).
Here’s a solution!
Split your build process into two steps, each step represents its own dockerfile.
-
Authenticate with external service in order to fetch sources (use private SSH key to authenticate with GitHub so you can clone a repo) and build the project.
-
Get build artifacts from step 1 and install them.
Tips and tricks to write Dockerfiles
After my yesterday talk at DevConf 2016 I got asked about some tips and tricks how to write Dockerfiles. I know we have plenty of resources for that in Red Hat, Fedora and Project Atomic. So, here we go!
…Installing python packages from git via pip
It may happen that you need to install a python project with pip from git(hub). That’s pretty easy:
…Copy your private GPG key to a new machine
It’s really simple to copy your private GPG keys to another machine of yours. Let’s do public key first: $ gpg --export --armor KEY | ssh me@my-other-machine 'gpg --import' gpg: keyring `/home/me/.gnupg/secring.gpg' created gpg: keyring `/home/me/.gnupg/pubring.gpg' created gpg: /home/me/.gnupg/trustdb.gpg: trustdb created gpg: key 4937B925: public key "KEY" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) It worked! Now the private: $ gpg --export-secret-key --armor KEY | ssh me@my-other-machine 'gpg --import --allow-secret-key-import' gpg: key 4937B925: secret key imported gpg: key 4937B925: "KEY" not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 (--armor is optional, it’s just for sake of checking the output first before piping it to ssh)…
Build docker engine on Fedora
It’s not that hard, here are a couple pain points:
- make sure that
GOPATHis right — you want to compile against your checked out docker, not master docker