7 ms·

Phusion Passenger Docker

69 points by Lazare 12y ago

neebz 12y ago
Would this work on AWS EC2 Instances? Amazon runs it's own variation of Linux which is different from the base image of this docker i.e. Ubuntu 14.04 LTS ?
- tinco 12y ago
  Yes, as long as your kernel is new enough to support Docker (and that of 14.04 is) then your Docker container will run on it, no matter what the base image is. This is thanks to Linux' relentless binary API backwards compatibility. The only thing your container interacts with is the kernel, and the API of the kernel never changes, so it'll run on any Linux operating system that's new enough to run Docker at all (and is 64-bit).
- nickstinemates 12y ago
  Docker is distributed as a part of Amazon Linux
whatwhynonono 12y ago
Using this Docker image doesn't give you one of the big benefits of Docker: being able to package your application in a light-weight way. This image creates an entire init system inside of Docker! May as well just use a virtual machine at that point. * Ruby: https://registry.hub.docker.com/_/ruby/ * Python: https://registry.hub.docker.com/_/python/ * Node: https://registry.hub.docker.com/_/node/ * Meteor: https://registry.hub.docker.com/u/danieldent/meteor/ What's special about those? You get an ONBUILD version too. You can package up your app along with Python/Ruby/Node/Meteor. And the other dependencies (i.e. database) have Docker images of their own that you can use. Nice and composable, reproducible infrastructure. This phusion-passenger-all-in-one monstrosity puts us back in the pre-Docker days.
- tinco 12y ago
  You do realize that 'an entire init system' is a 100 line python script right? Packaging your application in a 'light-weight' way is not one of the big benefits of Docker. Packaging your application in an isolated environment is _the_ big benefit of Docker, and that's exactly the benefit you get with this image. There's nothing monstrous about this image. It's based on the official Ubuntu image, has a few extra packages installed to satisfy some more dependencies so it's easier to use for other users, and Passenger itself is just a few MB. You probably don't get Docker very well. The idea is that you start a Docker container, and after a while a service is online on the port you EXPOSE-d. If a container satisfies those properties, then it's as composable and reproducible as any other. It's the magic of Docker.
- FooBarWidget 12y ago
  I am the author of passenger-docker. It is not true that this image is like creating a virtual machine, or that it is not lightweight. The image is very-much in line with the Docker philosophy, as I’ve described in this blog post: http://blog.phusion.nl/2015/01/20/baseimage-docker-fat-containers-treating-containers-vms/ http://blog.phusion.nl/2015/01/20/baseimage-docker-fat-conta... You talked about “an entire init system”, but this init system is a lightweight, stripped down variant written especially for Docker. The entire thing is just a few hundred lines Python script. You may be thinking that an init system is not necessary in Docker, but that is not true, as I’ve explained in “Docker and the PID 1 zombie reaping problem”: http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombi... With passenger-docker, you only create an image with your web app in it, plus an app server to run that web app. Nothing more. The database is still external. Memcached and Redis are not installed unless you explicitly enable them. The image is lightweight as you can expect from Ruby, Python and Node.js apps. In fact, we've explicitly split the image 8 variants, each variant containing only the minimum possible: https://github.com/phusion/passenger-docker#image_variants https://github.com/phusion/passenger-docker#image_variants Passenger-docker is very much in line with the idea of composable, reproducible infrastructure. Nothing in passenger-docker violates those principles.
  - KurtMueller 12y ago
fit2rule 12y ago
I'd love to have one of these, but for OpenResty and luvit. Lua, in other words.
aliem 12y ago
As I see this it's yet another attempt to use containers for virtualization. I'm sorry if I am completely missing the point of this effort.
- teh_klev 12y ago
  I think you are, see: https://news.ycombinator.com/item?id=8971353 https://news.ycombinator.com/item?id=8971353
totallymike 12y ago
I remember playing with this image back in July. It's pretty handy, and pretty easy to get up and running. What's changed about it recently that it's getting publicity again?
- FooBarWidget 12y ago
  You can consult the changelog for the history of changes. Various improvements have been contributed by the community. Things are more polished and bugs have been fixed.
lukebennett 12y ago
Generally it's best to have one role (some would say one process but that isn't always pragmatic) per container. This approach advocates having multiple roles within the same container (e.g. app, db). I can appreciate the benefits of the underlying phusion-baseimage for addressing some common pitfalls and hurdles, but this layer on top takes things too far in my opinion. Ok, you have the option to customise it, but that comes across as an optional extra rather than an advised approach.
- FooBarWidget 12y ago
  This is false. This image does NOT advocate multiple roles in the same container. Passenger-docker does NOT come with a database. It provides the option to have memcached and Redis inside the container, but it is optional and not installed by default. You have to explicitly enable them. Passenger-docker only handles a single role: the app. Depending on your viewpoint, caching may or may not be considered to be a logical part of the app. This is why we provide the option. But again, disabled by default because we go for lightweight by default.
  - lukebennett 12y ago
    I didn't say that it came with a database, I said that it advocates multiple roles per container - skim down the list of what's included and you see multiple languages, web server, app server, aux services and tools. First impressions are that this image is one-size-fits-all (Whilst I can perceive a distinction myself, I can understand why others in this thread have taken this to be an attempt at emulating a VM). I take your point that there may be situations where it's pragmatic to have memcached/Redis in the same container as your app, and that they are disabled by default, but I still feel the balance of the README is wrong as it doesn't sound any kind of warning that you probably don't want to do that in most cases. I'd suggest the README could be improved to better communicate the intended use cases of the images.
    - FooBarWidget 12y ago
      > and you see multiple languages But they're not all included in the same image. We have 8 variants, 6 of which only contain a single language. There is 1 which contains everything, and there's 1 which contains nothing and is meant for customization. > web server, app server The web server and the app server are the same thing. Passenger is an Nginx module. > aux services and tools. Only the minimum possible to allow regular administration, inspection and debugging. > First impressions are that this image is one-size-fits-all But it is not. That's why we have 8 variants. Early in development we've explicitly made this a many-sizes-fit-all thing. > and that they are disabled by default, but I still feel the balance of the README is wrong as it doesn't sound any kind of warning that you probably don't want to do that in most cases. Fair enough, though I disagree. I'd rather assume the user knows what he's doing. If he chose to enable Redis then there's probably a good reason for that.
KurtMueller 12y ago
Does anybody know of any Chef/Puppet/Ansible/Salt like service for Docker containers? Yes, I understand that Dockers are easily reproducible and you throw them away and replace them after updating its configuration. However, there has to be something to manage the docker containers themselves - I imagine after 10 or so container sitting on a vm, it could get unruly to manage by hand. Also, I've listened to speakers that mention long lasting services (like a database) should be handled differently in Dockerland - however, nobody I've listened to has spoken extensively about it.
- lukebennett 12y ago
  This is an area where there's a lot of growth in tools/services/approaches. A couple to start you off with are Fig[1] (acquired last year by Docker themselves) and Shipyard[2]. [1] http://www.fig.sh/ http://www.fig.sh/ [2] http://shipyard-project.com/ http://shipyard-project.com/
- bkeroack 12y ago
  I believe you're looking for something like http://packer.io http://packer.io
- mikexstudios 12y ago
  I've been using Chef + the chef-docker cookbook (https://github.com/bflad/chef-docker https://github.com/bflad/chef-docker) to setup docker containers.
- simple10 12y ago
  We have a nice Docker dev + production automation system that we developed for early Airstack customers. It uses Vagrant to manage VMs for both local dev and remote dev|test|prod. Then Salt to install Docker and Fig on the VM and run Heroku-like commands through salt states. The fig.yml is controlled by salt to allow jinja scripting of variables like RAILS_ENV, databases, etc. It works well. Clean separation of concerns between Vagrant (VM mgmt), Salt (provisioning and controller), and Docker (code) goes a long way towards a creating a pleasant DevOps experience. In dev mode, we share local folders (./app) into the VM (/srv/app) and bind mount the VM folder into containers. In prod, we rsync code to the VM and bind mount into the containers. For gems and other dependencies, we bundle them in the VM and bind mount them into Docker containers (non-trivial due to path issues) for both dev and prod. This flow makes it a lot more intuitive for devs who are used to running everything on their laptops. Code is still edited locally, but to update gems, a dev just runs `make bundle` instead of `bundle install` to trigger bundling in the VM. We're planning on open sourcing parts of the system when we have a chance to finish the documentation. In the meantime, feel free to reach out if you want early access. Email on github[1]. [1] https://github.com/simple10 https://github.com/simple10

69 points by Lazare 12y ago

neebz 12y ago

Would this work on AWS EC2 Instances? Amazon runs it's own variation of Linux which is different from the base image of this docker i.e. Ubuntu 14.04 LTS ?

tinco 12y ago
Yes, as long as your kernel is new enough to support Docker (and that of 14.04 is) then your Docker container will run on it, no matter what the base image is. This is thanks to Linux' relentless binary API backwards compatibility. The only thing your container interacts with is the kernel, and the API of the kernel never changes, so it'll run on any Linux operating system that's new enough to run Docker at all (and is 64-bit).
nickstinemates 12y ago
Docker is distributed as a part of Amazon Linux

whatwhynonono 12y ago

Using this Docker image doesn't give you one of the big benefits of Docker: being able to package your application in a light-weight way. This image creates an entire init system inside of Docker! May as well just use a virtual machine at that point. * Ruby: https://registry.hub.docker.com/_/ruby/ * Python: https://registry.hub.docker.com/_/python/ * Node: https://registry.hub.docker.com/_/node/ * Meteor: https://registry.hub.docker.com/u/danieldent/meteor/ What's special about those? You get an ONBUILD version too. You can package up your app along with Python/Ruby/Node/Meteor. And the other dependencies (i.e. database) have Docker images of their own that you can use. Nice and composable, reproducible infrastructure. This phusion-passenger-all-in-one monstrosity puts us back in the pre-Docker days.

tinco 12y ago
You do realize that 'an entire init system' is a 100 line python script right? Packaging your application in a 'light-weight' way is not one of the big benefits of Docker. Packaging your application in an isolated environment is _the_ big benefit of Docker, and that's exactly the benefit you get with this image. There's nothing monstrous about this image. It's based on the official Ubuntu image, has a few extra packages installed to satisfy some more dependencies so it's easier to use for other users, and Passenger itself is just a few MB. You probably don't get Docker very well. The idea is that you start a Docker container, and after a while a service is online on the port you EXPOSE-d. If a container satisfies those properties, then it's as composable and reproducible as any other. It's the magic of Docker.
FooBarWidget 12y ago
I am the author of passenger-docker. It is not true that this image is like creating a virtual machine, or that it is not lightweight. The image is very-much in line with the Docker philosophy, as I’ve described in this blog post: http://blog.phusion.nl/2015/01/20/baseimage-docker-fat-containers-treating-containers-vms/ http://blog.phusion.nl/2015/01/20/baseimage-docker-fat-conta... You talked about “an entire init system”, but this init system is a lightweight, stripped down variant written especially for Docker. The entire thing is just a few hundred lines Python script. You may be thinking that an init system is not necessary in Docker, but that is not true, as I’ve explained in “Docker and the PID 1 zombie reaping problem”: http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombi... With passenger-docker, you only create an image with your web app in it, plus an app server to run that web app. Nothing more. The database is still external. Memcached and Redis are not installed unless you explicitly enable them. The image is lightweight as you can expect from Ruby, Python and Node.js apps. In fact, we've explicitly split the image 8 variants, each variant containing only the minimum possible: https://github.com/phusion/passenger-docker#image_variants https://github.com/phusion/passenger-docker#image_variants Passenger-docker is very much in line with the idea of composable, reproducible infrastructure. Nothing in passenger-docker violates those principles.
- KurtMueller 12y ago

fit2rule 12y ago

I'd love to have one of these, but for OpenResty and luvit. Lua, in other words.

aliem 12y ago

As I see this it's yet another attempt to use containers for virtualization. I'm sorry if I am completely missing the point of this effort.

teh_klev 12y ago
I think you are, see: https://news.ycombinator.com/item?id=8971353 https://news.ycombinator.com/item?id=8971353

totallymike 12y ago

I remember playing with this image back in July. It's pretty handy, and pretty easy to get up and running. What's changed about it recently that it's getting publicity again?

FooBarWidget 12y ago
You can consult the changelog for the history of changes. Various improvements have been contributed by the community. Things are more polished and bugs have been fixed.

lukebennett 12y ago

Generally it's best to have one role (some would say one process but that isn't always pragmatic) per container. This approach advocates having multiple roles within the same container (e.g. app, db). I can appreciate the benefits of the underlying phusion-baseimage for addressing some common pitfalls and hurdles, but this layer on top takes things too far in my opinion. Ok, you have the option to customise it, but that comes across as an optional extra rather than an advised approach.

FooBarWidget 12y ago
This is false. This image does NOT advocate multiple roles in the same container. Passenger-docker does NOT come with a database. It provides the option to have memcached and Redis inside the container, but it is optional and not installed by default. You have to explicitly enable them. Passenger-docker only handles a single role: the app. Depending on your viewpoint, caching may or may not be considered to be a logical part of the app. This is why we provide the option. But again, disabled by default because we go for lightweight by default.
- lukebennett 12y ago
  I didn't say that it came with a database, I said that it advocates multiple roles per container - skim down the list of what's included and you see multiple languages, web server, app server, aux services and tools. First impressions are that this image is one-size-fits-all (Whilst I can perceive a distinction myself, I can understand why others in this thread have taken this to be an attempt at emulating a VM). I take your point that there may be situations where it's pragmatic to have memcached/Redis in the same container as your app, and that they are disabled by default, but I still feel the balance of the README is wrong as it doesn't sound any kind of warning that you probably don't want to do that in most cases. I'd suggest the README could be improved to better communicate the intended use cases of the images.
  - FooBarWidget 12y ago
    > and you see multiple languages But they're not all included in the same image. We have 8 variants, 6 of which only contain a single language. There is 1 which contains everything, and there's 1 which contains nothing and is meant for customization. > web server, app server The web server and the app server are the same thing. Passenger is an Nginx module. > aux services and tools. Only the minimum possible to allow regular administration, inspection and debugging. > First impressions are that this image is one-size-fits-all But it is not. That's why we have 8 variants. Early in development we've explicitly made this a many-sizes-fit-all thing. > and that they are disabled by default, but I still feel the balance of the README is wrong as it doesn't sound any kind of warning that you probably don't want to do that in most cases. Fair enough, though I disagree. I'd rather assume the user knows what he's doing. If he chose to enable Redis then there's probably a good reason for that.

KurtMueller 12y ago

Does anybody know of any Chef/Puppet/Ansible/Salt like service for Docker containers? Yes, I understand that Dockers are easily reproducible and you throw them away and replace them after updating its configuration. However, there has to be something to manage the docker containers themselves - I imagine after 10 or so container sitting on a vm, it could get unruly to manage by hand. Also, I've listened to speakers that mention long lasting services (like a database) should be handled differently in Dockerland - however, nobody I've listened to has spoken extensively about it.

lukebennett 12y ago
This is an area where there's a lot of growth in tools/services/approaches. A couple to start you off with are Fig[1] (acquired last year by Docker themselves) and Shipyard[2]. [1] http://www.fig.sh/ http://www.fig.sh/ [2] http://shipyard-project.com/ http://shipyard-project.com/
bkeroack 12y ago
I believe you're looking for something like http://packer.io http://packer.io
mikexstudios 12y ago
I've been using Chef + the chef-docker cookbook (https://github.com/bflad/chef-docker https://github.com/bflad/chef-docker) to setup docker containers.
simple10 12y ago
We have a nice Docker dev + production automation system that we developed for early Airstack customers. It uses Vagrant to manage VMs for both local dev and remote dev|test|prod. Then Salt to install Docker and Fig on the VM and run Heroku-like commands through salt states. The fig.yml is controlled by salt to allow jinja scripting of variables like RAILS_ENV, databases, etc. It works well. Clean separation of concerns between Vagrant (VM mgmt), Salt (provisioning and controller), and Docker (code) goes a long way towards a creating a pleasant DevOps experience. In dev mode, we share local folders (./app) into the VM (/srv/app) and bind mount the VM folder into containers. In prod, we rsync code to the VM and bind mount into the containers. For gems and other dependencies, we bundle them in the VM and bind mount them into Docker containers (non-trivial due to path issues) for both dev and prod. This flow makes it a lot more intuitive for devs who are used to running everything on their laptops. Code is still edited locally, but to update gems, a dev just runs `make bundle` instead of `bundle install` to trigger bundling in the VM. We're planning on open sourcing parts of the system when we have a chance to finish the documentation. In the meantime, feel free to reach out if you want early access. Email on github[1]. [1] https://github.com/simple10 https://github.com/simple10