> having a single artifact and reproducible builds where a developer can run the docker image locally
This is the key thing here. As a team grows it’s easy to get various kinds of learned helplessness. Docker, for its faults, is mostly simple enough that you can expect/insist that the team use it. Which means fewer kinds of surprises at deployment time.
We enforced that by giving our devs linux workstations with no sudo rights (iso27001 requirement), but they have access to the docker daemon, and MUST install everything they need in docker images, its massively increased tools sharing between teams, and forced people to learn docker. We have some devs starting to use kubernetes locally using minikube .
Sorry for being off-topic but do you have any links or tips on how to achieve this? My understand was that adding a user to the 'docker' group gives him 'sudo'-equivalent rights.
Re:Convergence to Kubernetes
by asfdsfggtfd on Monday June 25, 2018 @02:51AM
(#17390401)
You can set it up so that the user doesn't have to type sudo docker. But they still effectively have root access via docker.
I guess it gives some social pressure not to do superuser things?
Re:Convergence to Kubernetes
by de_watcher on Monday June 25, 2018 @10:56AM
(#17392878)
It looks like a package manager choice. Dpkg/Apt isn't doing by default what they actually need, so they use Docker instead.
Re:Convergence to Kubernetes
by alexandre_m on Monday June 25, 2018 @11:25AM
(#17393112)
Your devs can pass --privileged to docker run, that gives them root.
Re:Convergence to Kubernetes
by zwischenzug on Monday June 25, 2018 @03:48AM
(#17390638)
Depends who's doing the choosing. Where it takes months to provision a 'real' server, Docker saves an awful lot of time and effort.
But most people choose Docker because it's well-known, well supported, and the experience outside corporate environments is a joy.
docker containers are not reproducible.
if you built the same content on machine a and built the same content on machine b the hash of the image would differ. and the timestamp probably too
As far as constantly rebuilding and deploying things, we would be doing that anyway. We do dozens of deploys a day to push new code, that means building new images every time, if one of those deploys picks up a security fix that was recently merged upstream, great.