-
Notifications
You must be signed in to change notification settings - Fork 14
Conversation
@lox @blueimp @yoshuawuyts @rimusz do you have any thoughts on this? Also this is kinda blocked on #37 as well, although that's going to have to be dealt with regardless. |
66664f3
to
6ac785c
Compare
I like it, as it's simpler and provides a reproducible Dockerfile. There's just one minor caveat with the following code:
This will double the size of the buildkite-agent in the docker image, as it creates a second layer with a changed binary. |
@blueimp ah nice! I thought you might catch something like that. |
You're welcome. We're quite fond of buildkite and I'm happy to help. :) Just last week I was working on our custom buildkite-agent and considered to base it on your official one. With the changes proposed in this PR, I'd definitely do it, as it makes it very easy to extend. One more suggestion I have is to default the user of the buildkite-agent to an unprivileged one. We use the following Dockerfile instructions for this:
#!/bin/sh
# shellcheck shell=dash
for file in /usr/local/etc/entrypoint.d/*; do
[ -x "$file" ] && "$file";
done;
exec "$@" One of the scripts in
One might argue that docker users are alike to root, so there's no security benefit here. |
Thanks. That was the intention of #18 and don't see why we couldn't do it in this new one. Why all the Docker stuff though? Are you including Docker daemon in your own image? |
No, we're mounting the host docker socket into the buildkite container. btw. I would definitely use |
Cool to see an
This will def mess with my |
Hi @toolmantim, |
Nice idea to set a uid! I'm a little worried about using UID 1000 for all docker users because we don't know how uids are allocated on the host system, and a typical pattern is to volume map in the builds directory etc, which might leave files belonging to an unintended user lying about on the host. I'm not sure this is worse than leaving root-owned files about the place, but it might mislead folks that the setup is secured. Perhaps we can find another default. The nobody user is usually the last uid, 65534? But sometimes it can be 99? Or just choose something typically before the user-allocated uids, like 99 or 999? |
Will the lack of docker (client) and wget / curl drive people nuts? |
@sj26 Since Docker has user namespaces now, using a different user than root is less of a security benefit. For us it's mainly a development benefit. |
perl \ | ||
openssh-client | ||
|
||
ENV BUILDKITE_AGENT_VERSION 3.0-beta.10.1323 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a build argument?
@blueimp right, that's super annoying. We had to work around it specifically in the Elastic CI Stack. I don't think we can roll that into the main distribution though because not all users are running Docker for Mac / boot2docker / etc. so UID 1000 might not be as intended. Recommending user namespaces would be good, though! |
User namespaces get complicated quickly when the container creates multiple users, which happens in sufficiently complicated containers fairly often. |
I'm keen to see this happen, the current images are already quite behind docker. |
@toolmantim bump! :) |
I'd like to get this done too, but there's a few things that still need to be figured out:
The full list of tags we have currently are here: |
My take would be to include the Docker 1.13 client, which introduced interoperability with older server versions. I'd also include curl. I'm starting to come around to @blueimp's |
@lox Thanks for the shoutout :)! As a side-note, we're probably moving away from the docker image, as by now we would definitely benefit from the auto-scaling buildkite/elastic-ci-stack-for-aws. P.S.: I just realised you're not actually working for BuildKite. |
@blueimp my renewed interest in the docker image is that I'd really like buildkite/elastic-ci-stack-for-aws to use docker images for the agents. Ideally this lets us iterate on the agent versions / images quicker than the aws stack images. How would you feel about that? |
That would combine the advantages of both, so I'm all for it. :) |
Superseded by #44 |
This cuts everything down to three images that can more easily be built locally:
Things that are gone:
buildkite/agent-docker
where we can go crazy with Docker version tags, etccurl
andwget
Things still needing to be done: