11–20 of 30 posts
The article should mention why you would like to run something in docker. What many forget is that when putting stuff in a container, you create future work for yourself to manage not only your own stuff, but also all the dependencies in the container. If you're just after isolation, that could be accomplished with Linux name-spaces and apparmor.
I think it's brilliant that this gives security more prominence with setting up the unprivileged user. Pretty much every Docker post / article I've seen tends to skip over details like that.
What exactly do you achieve with this? It's running in a container. What's a hacker to do? Screw up the app in the container, which they could do with the app user anyway?
Running as a non-root user in the container is an extra level of protection and follows the principle of least privilege.
I think it's brilliant that this gives security more prominence with setting up the unprivileged user. Pretty much every Docker post / article I've seen tends to skip over details like that.
What exactly do you achieve with this? It's running in a container. What's a hacker to do? Screw up the app in the container, which they could do with the app user anyway?
[1] https://en.wikipedia.org/wiki/Principle_of_least_privilege
The article should mention why you would like to run something in docker. What many forget is that when putting stuff in a container, you create future work for yourself to manage not only your own stuff, but also all the dependencies in the container. If you're just after isolation, that could be accomplished with Linux name-spaces and apparmor.
It think it's worked pretty well so far, though we have had a few difficulties:
- Particularly in the early stages of development, we've been changing dependencies a lot, and that requires a lot of image rebuilds. They are very consistent, but also a bit tedious.
- For those of us on macs, using docker machine for development hasn't been all that great, because inotify doesn't work for automatic code reloading (watchify, nodemon, etc.). However, they're hard at work on that with the new Docker for Mac.
I'm hopeful that technologies like kubernetes will make it easier to deploy these containers, too, but I haven't really got there yet. Maybe another article some day!
The article should mention why you would like to run something in docker. What many forget is that when putting stuff in a container, you create future work for yourself to manage not only your own stuff, but also all the dependencies in the container. If you're just after isolation, that could be accomplished with Linux name-spaces and apparmor.
The article should mention why you would like to run something in docker. What many forget is that when putting stuff in a container, you create future work for yourself to manage not only your own stuff, but also all the dependencies in the container. If you're just after isolation, that could be accomplished with Linux name-spaces and apparmor.
(Author here.) That's a good question. In this case, the main benefit I was after was easy setup of consistent development environments. We have in the past (and still do) use vagrant + ansible for the same purpose, but Dockerfiles are a lot simpler, and people have been less afraid of changing them vs. the slightly crazy ansible playbooks. It think it's worked pretty well so far, though we have had a few difficultie…
The article should mention why you would like to run something in docker. What many forget is that when putting stuff in a container, you create future work for yourself to manage not only your own stuff, but also all the dependencies in the container. If you're just after isolation, that could be accomplished with Linux name-spaces and apparmor.
(Author here.) That's a good question. In this case, the main benefit I was after was easy setup of consistent development environments. We have in the past (and still do) use vagrant + ansible for the same purpose, but Dockerfiles are a lot simpler, and people have been less afraid of changing them vs. the slightly crazy ansible playbooks. It think it's worked pretty well so far, though we have had a few difficultie…
The article should mention why you would like to run something in docker. What many forget is that when putting stuff in a container, you create future work for yourself to manage not only your own stuff, but also all the dependencies in the container. If you're just after isolation, that could be accomplished with Linux name-spaces and apparmor.
- OS packaging is tedious to say the least, and "git clone and pull dependencies on production systems" processes are generally considered messy (if not evil, especially when pulling from repositories hosted on the internet); Docker solves both of these issues by offering a generic interface for shipping and deploying isolated instances of your application. You don't get that with just namespaces and apparmor, you need an API for that (which is really what makes Docker so useful)
- Docker (potentially with the help of its ecosystem) can provide a uniform interface to a couple of the most important operational aspects of an application: logging and monitoring. Especially for heterogeneous or simply large environments, this is a big win.
- When container deployment orchestration matures more, it is much easier to manage and auto-scale your application in a large scale setting since you don't need to reinvent that wheel for every specific stack out there. It will come.
- It makes setting up and understanding development environments easier. Similar to Vagrant, Docker Compose lets you describe your architecture in a config file and easily set up a full stack for you. Especially in companies supporting or developing for a complicated stack, that's very useful. It also probably makes on-boarding of new developers a lot easier.
Still you're making a valid point: you need to maintain those containers. Just like you need to maintain your application's dependencies. Let's be honest though, in many ecosystems that problem already exists: take your typical JEE application that once built, hardly ever upgrades its dependency list anymore (no one even monitors what security holes are being found in all those jars, in many cases). But yes, you should. That problem is really not solved with Docker containers. Most images/containers will be as thin as possible (as will the host OS, preferably), but the concern remains valid.
RUN npm config set registry https://registry.npmjs.org/
I don't know why it works, but it does.
Any reason why you wouldn't use some kind of supervision for your process when running it in production?
Docker itself can restart containers when the parent process inside the container exits for any reason. That behavior is not enabled by default but it can trivially be enabled for a container (started via "docker run", or in the compose yml file similarly). https://docs.docker.com/compose/compose-file/#cpu-shares-cpu...