21–30 of 30 posts
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?
If your NPM installs are mysteriously slow in Docker, try adding this line before 'npm install': RUN npm config set registry https://registry.npmjs.org/ I don't know why it works, but it does.
https://imagelayers.io/?images=node:4.3.2 - I wonder how small we could get an image that's still capable of running node and having an extra user (Buildroot is root-only by default)
If the image size is your primary concern, there are many alpine linux images which excel at this, for example: https://github.com/mhart/alpine-node
If your NPM installs are mysteriously slow in Docker, try adding this line before 'npm install': RUN npm config set registry https://registry.npmjs.org/ I don't know why it works, but it does.
Can anyone tell me what this does? This looks like a configuration files in JSON, but why do these setting make it work in docker? If my docker image size is different, which parameter in this would I change?
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.
Earlier quoted context omitted.
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...
The last time I tried to use that it failed when coupling containers. Ie that nginx requires, my web app, which requires the database. Every process but the database failed because they all depended on each other. I ended up using shell scripts which used an arbitrary wait of 2 seconds after each process. that fixed the problem so that the containers came up after a reboot. Did docker fix that yet?
But that "links break when containers restart or are replaced" aspect was a deal-breaker for me when I started using docker "near production". I just use --net=host ... so I don't use docker network-related functionality at all. For my purposes server-level firewall settings are fine.
Earlier quoted context omitted.
If the image size is your primary concern, there are many alpine linux images which excel at this, for example: https://github.com/mhart/alpine-node
mhart's images are great, but I have found one issue with them. They do not contain the dependencies needed to build node-gyp based packages, more specifically and critical bcrypt package. I have fixed this issue and have pushed and maintain up-to-date node images that are built on alpine and have make, g++, etc that is needed. https://github.com/stackci/node
Earlier quoted context omitted.
(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…
Check out docker-osx-dev which uses rsync to more efficiently synchronize container volumes with your local files and enable watchers.
Earlier quoted context omitted.
mhart's images are great, but I have found one issue with them. They do not contain the dependencies needed to build node-gyp based packages, more specifically and critical bcrypt package. I have fixed this issue and have pushed and maintain up-to-date node images that are built on alpine and have make, g++, etc that is needed. https://github.com/stackci/node
Should g++/make really be included in a container that's used in production though?
Earlier quoted context omitted.
Should g++/make really be included in a container that's used in production though?
If you use the bcrypt node package you need g++/make to compile native extensions so there's really no way to avoid it. You can remove it after you run `npm install` in your own dockerfile, but it won't help container size at all.