4 ms·
The big problem is that docker/container image creation is now buried deep inside an app's build system. This means that your build system is now a critical par
by KaiserPro 12y ago
The big problem is that docker/container image creation is now buried deep inside an app's build system. This means that your build system is now a critical part of your infrastructure.
- parasubvert 12y agoIsn't that the case with any continuous deployment pipeline? Best to use the CD system to do the deploy, and avoid "hold my beer, I've got to emergency deploy this via SSH" which is high risk for minimal gain.
- KaiserPro 12y agoNo I don't mean pushing patches to your App, I mean critical system libraries. Because they are baked into the container, to do critical patches you need to rebake the image. The Docker bit will be mostly painless, unless you've don't something stupid, however the bits around the app can and will changes. The amount of times I've tried to use a build job from 3-6months ago and it fails horrifically is far too often.
- mpdehaan2 12y agoauthor here. I'm assuming you have your organization's docker files in soure control and Jenkins, MAYBE you are buildling on top of the Ubuntu base image. So it shouldn't be buried - you should be able to update in source control and rebuild. (Also, this post is mostly applicable to AMIs). And 100% absolutely, your build system SHOULD be a critical part of your infrastructure. Not mission critical in that it being down is a problem, but it's how you role out changes. This also allows you to continuously test the software going into builds, have dependencies, and all of those things. This is "continuous integration + continuous deployment", but it doesn't have to be continuous. But continuous is a (cough) continuum and there are steps down that road that yield benefits without going all the way.