4 ms·
Phoenix Framework dockerfile
- sacheendra 11y agoWhy is this even on the first page? This is a Dockerfile. How is this supposed to be of general interest and generate good conversation? Hope this is not a signal of the future of HackerNews.
- rajeemcariazo 11y agoThis is worthy of my up vote because I've tried setting up phoenix framework on fresh Ubuntu and it's a pain in the ass
- hosh 11y agoIt is? Most of my problem was with Node.js and not with Erlang or Elixir.
- joshmanders 11y agoWhat's your problem with node? I do a lot of Node with Docker so I might be able to help.
- bpicolo 11y agoUbuntu doesn't have a convenient apt command for latest node. And there is renaming of the binary from node -> nodejs which breaks things. There's some not-built-in apt repos to fix it
- fishnchips 11y agoThe problem is that Phoenix requires Node 5 and the current stable (which is what vanilla apt-get will install) is 4. Which is indeed a bit confusing.
- joshmanders 11y agoAh I see, why does Phoenix require Node 5?
- deathtrader666 11y agoPhoenix needs NodeJS for the asset pipeline of the frontend.
- hosh 11y agoYep. Which if we were just creating something without a front-end, then we can ditch the whole node ecosystem.
- nilliams 11y agoI generally recommend using nvm [1] to install Node, it's certainly a painless way to get Node 5, then it's also easy to switch version later, or maybe downgrade to the LTS when you're doing 'work work' (`nvm use 4`). Just remember to set a default, e.g. if you're mostly using Node for Phoenix: `nvm alias default 5`. It also sets up your global modules directory so that you don't need sudo to install global modules like gulp-cli (should you need any, though it's quite rare that you do nowadays). [1] https://github.com/creationix/nvm https://github.com/creationix/nvm
- joshmanders 11y ago> Hope this is not a signal of the future of HackerNews. I hope attitudes like this isn't a signal of the future of Hacker News.
- indatawetrust 11y agothis was my first attempt dockerfile. thank you for your interest :)
- extrapickles 11y agoLooks good for a first dockerfile. You may want to try combining several of the run commands together to save on the number of layers generated and improve the final size. A good rule of thumb is to combine if the command can touch the files of a previous command. Then it becomes easy to clean up after downloading a package (no need to have the downloaded version and the installed).
- manojlds 11y agoUse phusion base image as a guide for best practices around RUN steps and cleanup.
- bgentry 11y agoNice first pass! I haven't looked at the final image size, but I suspect that starting with ubuntu:latest means that you'll have a pretty large resulting image with a bunch of unnecessary software installed. For your next attempt, you might want to look into creating a more slim image that contains only the required dependencies. I guess an alternate version of this would be one which has the core Phoenix dependencies but none of the asset management / Node.js stuff. I have a Phoenix API w/ no assets that could use such an image :)
- zenlikethat 11y agoEven just switching Ubuntu out for Debian can shave off ~50MB and rarely requires additional modfications IME (unless using something Ubuntu specific).
- BlackjackCF 11y agoAgreed with the statements about combining your run layers. The fewer layers you have the better. Also, I would try to build this using Alpine or another smaller Linux distro.
- hazbo 11y agoThis has inspired me to quickly knock up a Dockerfile for fans of Alpine based containers, if anyone is interested. https://github.com/hazbo/phoenix-docker-alpine https://github.com/hazbo/phoenix-docker-alpine
- fishnchips 11y agoMy take on the same topic: https://github.com/codequest-eu/phoenix-alpine https://github.com/codequest-eu/phoenix-alpine I found out that the `update-ca-certificates` step is required if you have GitHub dependencies.
- arianvanp 11y agoDockerfiles for phoenix kind of miss the point of the erlang ecosystem. Erlang already has its own 'docker' . Erlang can be packaged up as "releases" that have no dependencies whatsoever. It's like fat java jars, including the VM itself. They ship with the Erlang VM and they allow zero-downtime upgrades. http://erlang.org/doc/man/relup.html http://erlang.org/doc/man/relup.html
- tobz 11y agoI don't think it misses the point of Erlang/Elixir at all. 1) Docker is a popular project for running applications in containers. This is a familiar deployment pattern for many devs(ops) people, so it's yet another option someone has. 2) Most people using Phoenix are probably not using bare-metal, which is the only real scenario I can think of that lets you easily say "we don't need anything except for Erlang's hot code reloading". All cloud-y offerings will be potentially transient, hell, so will bare-metal. Most people will have infrastructure/tooling to provision new capacity easily, and to handle capacity being lost to failure. They almost certainly have, already, patterns for replacing containers in and out of their load balancers, etc, to avoid the need for hot code reload. I think Erlang's system for doing it can be great, but if you already have a system to run a single command that replaces your app/web/whatever fleet with a new code version, then you're not inherently ignoring the benefits/features of Erlang/Elixir, you're just doing something else you're already comfortable with. Erlang has its own "docker", but Erlang runs on an OS, not the bare-metal host, so you still have to deal with getting it there and running it.
- rad_gruchalski 11y agoI believe what the person you're replying to is trying to say is: there is no need to build a Dockerfile for Erlang when using releases. Create a release for the target OS and simply start it from ebin. It comes with a VM packaged and can be run with zero dependencies. You can easily run it in a vanilla ubuntu image on k8s or mesos. No problem whatsoever running it directly on mesos without Docker overhead.