I never quite understood how Docker lets developers share the same development environment. Most Dockerfiles that I have seen are a series of apt-get install commands. If different people build images using the same Dockerfile at different times, isn't there a chance that they will pick up different package versions? What am I missing?
Some questions about Docker and rkt
71–80 of 92 posts
Re: Some questions about Docker and rkt
#72I never quite understood how Docker lets developers share the same development environment. Most Dockerfiles that I have seen are a series of apt-get install commands. If different people build images using the same Dockerfile at different times, isn't there a chance that they will pick up different package versions? What am I missing?
People just don't care about those small differences. (Since solutions of pedantic version pinning or vendoring are known, anyone who doesn't adopt them clearly doesn't care that much.)
Or you can have all the devs pull images built by a central CI system, but you'll still have package differences creep in over time.
Re: Some questions about Docker and rkt
#73Earlier quoted context omitted.
I think Kubernetes does a good job creating a normal "Unix process environment". The Pod concept allows for: - Container processes share localhost, mount points, etc - Providing a "normal" IP address that is routable - Ensuring a PID1 can monitor the group of processes (as done by rkt integration) - Allowing for normal POSIX IPC (signals, etc) More here: http://kubernetes.io/docs/user-guide/pods/ As for PetSets I do…
It definitely does better than many of the rest, in my experience, and for sure it has better defaults and chooses its violations carefully and generally wisely. In fact, I wrote the first draft of a paper on this specific topic: https://docs.google.com/document/d/1hw_0edCtZ8D4FYhc6oNRTAXm... delineating some of the more difficult and surprising violations and some possible remediation steps.
Having been inside Google when Docker started to get big, there's a really simple explanation for all of this:
Kubernetes is a well designed descendant of a well-designed API with pretty specific tradeoffs for distributed systems (that mostly still work at the small scale).
Docker is a reverse-engineered mishmash of experiments attempting to replicate the same ancestor. Things like the horrible network abstraction layer - Google had the advantage of being able to move all their apps to a well understood naming scheme, rather than treating IP addresses as immutable. That any app does this is technical debt, but it worked for a long time. Now it doesn't.
Docker has tried to fix these things by wrapping them, not fixing the underlying debt. That only ever accumulates more debt, and rarely even provides the stopgap solution that is required. It's an admirable effort, and they've done a fantastic job - but a fantastic job at a fool's errand is still not behavior to emulate.
Re: Some questions about Docker and rkt
#74I never quite understood how Docker lets developers share the same development environment. Most Dockerfiles that I have seen are a series of apt-get install commands. If different people build images using the same Dockerfile at different times, isn't there a chance that they will pick up different package versions? What am I missing?
Create a dockerfile that does performs installation of all the tools that you need, execute that once to create an image and then share the image with everyone else who needs it, possibly through a private registry.
We use that approach now to store some build environments for embedded systems, where our prebuilt and shared images contain all 3rd party dependencies (which are only slowly changing). We use then those images to build our own software. Depending on the use case we create new images from it, or only spawn containers for compiling something, copy the artifacts outside of the container and remove them again. Works really well for us.
Re: Some questions about Docker and rkt
#75"Installing stuff on computers so you can run your program on them really sucks. It's easy to get wrong! It's scary when you make changes! Even if you use Puppet or Chef or something to install the stuff on the computers, it sucks." I think a lot of people feel this way. I think that fear is born of ignorance, and we should fix that. Let's say you are working on an application in NewPopularLanguage 2.3.1, using CoolF…
> But if you really need the new versions, you should use a repeatable build system that generates OS packages exactly the way you want them. You should put them into a local repo so that when you install or upgrade a new machine, you get the version you specify, not whatever has just hit trunk upstream. And you may want your versions to be placed in a non-(system)-standard location, so that your application has to s…
When dealing with computers, the choice between "you have to be fucking careful" or "you can just use a X" has arisen many times.
I encourage my competitors to just use a X.
Re: Some questions about Docker and rkt
#76In terms of the daemon model of Docker, I guess it does look a bit complicated, and is not explained very well. In production you will do docker run -d nginx, not run it in the foreground, so the client (docker) process is not really in the picture - if you run in the foreground it is just there to stream the standard IO, and so you can kill the process with ^C from the shell. The docker daemon (dockerd) is there to…
TIL: live-restore
Re: Some questions about Docker and rkt
#77It seems that isolation is frequently the cause. E.g.: * Better developer environment. Actually, I'm not sure anymore. It totally makes sense for testing (all the CI/CD stuff), and - thanks to the packaging aspect - it's easy to set up external dependencies (like databases), but I just wasn't able to grasp how the actual development is better with Docker. Developers tinker with stuff, containers and images are all ab…
Developer environment/experience is vastly better in my opinion.
All of our dev environments are docker images. Setting up a machine for a developer is install source control, IDE & docker, then pull the latest dev image and they are done. Pre-docker it was several pages of documentation and tracking down various coworkers to make sure you installed&configured things correctly. While yes, scripts helped, people always forgot to update something in the script and didn't notice until someone needed to install the dev environment. The immutability forces people to actually update the dockerfiles with the new dependency/tool/config as that is the only way to do it.
Re: Some questions about Docker and rkt
#78While this thread has visibility, I am curious about your typical security model with docker. From my experience, whoever is running docker seems to be able to run root commands on the host [1]. So any best practices for running docker ? [1] http://reventlov.com/advisories/using-the-docker-command-to-...
You can use authorization plugins to control what commands are allowed. However generally you don't give people access to run any docker command in production, you have some system that lets them deploy containers with predetermined settings, which don't include being able to set --privileged or add capabilities or change security policies.
I am currently running docker with a systemd script (it seemed like a reasonable idea at the time).
But docker = sudo without password essentially.
So I am curious if there is a recommended way to run a service with a docker run.
Re: Some questions about Docker and rkt
#79So how do you handle what she addressed under secrets? How do you share passwords between containers? For quick and dirty stuff, I use environment variables that are set in my docker-compose file, but I have no experience running docker in production.
environment variables are problematic, as they can be read by other processes potentially. Vault or another secrets management tool is a better option. A secrets management solution integrated into Docker is planned, as it is difficult to get right without tooling support.
Is there a way to prevent other processes from reading environment variables?
Re: Some questions about Docker and rkt
#80"rkt" is such a strange name. In my head I don't pronounce it as "rocket" but as "rekt", with all the connotations that has.