We built this @ Techcrunch disrupt NYC last weekend, spent a few days cleaning it up and decided to opensource & share it with everyone. All feedback is welcome.
From what I understand, this tools build a container and push it to the registry for every change, where as when you are using the registry alone, you have to push the images manually?
The Docker Hub does also have a mode called "Automated Builds" which will pull down the repository, build an image based on the Dockerfile and push it. However, you do have to pick one or the other (you cannot push your own image to a repository configured as an Automated Build).
But you can manually trigger a build when automated builds are enabled, for rare cases when the automated trigger didn't do what you wanted. Works really well in practice.
This is actually a open source project you can host your self, so have your own version of dockerhub auto build plus we added a way to build repos without dockerfile with assigning default dockerfiles based on language and you can push to any registry you want. Be it dockerhub or quay or your own registry.
Also does the besides the stuff i mention in the other comment of, pushing to any registry, you can self host and modify, it also builds instantly and streams the logs.
I'm curious how security is handled with containerfactory.io.
We just gave a very detailed presentation on our build system at CoreOS Fest which will be available in video form soon. As a part of this talk, we mentioned all the security implications of building other people's container images.
Well the code to every part of this is open source so you can check and improve. The hosting part is on 10 digital ocean boxes all with one container on it so the build process is more isolated and anything goes wrong we kill and spawn a fresh box.
Docker executes builds as root which provides a build the opportunity to escape the container and become root on the host machine. In containerfactory.io's current hosted setup, there are no guarantees that the machine an image is being built on hasn't already been compromised by a previous build. Quay.io has traditionally worked around this problem by patching user namespaces into docker, but they come with their own set of incompatibilities. As a result, we have found the best solution is to never trust the build machines given the risk of credentials being taken or builds being manipulated. Hosting your own copy completely avoids this issue, if you trust the people you work with ;)
> Hosting your own copy completely avoids this issue, if you trust the people you work with ;)
We build containers from ephemeral t1.micros that only survive long enough to build the single container. I think that's secure enough for most orgs needs.
14 comments
[ 3.2 ms ] story [ 35.0 ms ] threadAm I right?
> plus we added a way to build repos without dockerfile with assigning default dockerfiles based on language and you can push to any registry you want
And applied to YC with it. Unfortunately they weren't accepted. I think it's a great concept.
If you'd like to chat more, my contact info is in my profile.
I'm curious how security is handled with containerfactory.io.
We just gave a very detailed presentation on our build system at CoreOS Fest which will be available in video form soon. As a part of this talk, we mentioned all the security implications of building other people's container images.
We build containers from ephemeral t1.micros that only survive long enough to build the single container. I think that's secure enough for most orgs needs.