Phusion Passenger Docker(github.com)
github.com
Phusion Passenger Docker
https://github.com/phusion/passenger-docker
7 comments
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/ [2] http://shipyard-project.com/
A couple to start you off with are Fig[1] (acquired last year by Docker themselves) and Shipyard[2].
[1] http://www.fig.sh/ [2] http://shipyard-project.com/
Aside from the aforementioned Fig, Shipyard, etc., here are a few more I've got bookmarked (i.e. I cannot vouch for how good they are):
http://panamax.io
https://www.tutum.co
https://github.com/nitrous-io/tug
https://www.digitalocean.com/community/tutorials/how-to-use-...
https://github.com/spotify/helios
http://panamax.io
https://www.tutum.co
https://github.com/nitrous-io/tug
https://www.digitalocean.com/community/tutorials/how-to-use-...
https://github.com/spotify/helios
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
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
I've been using Chef + the chef-docker cookbook (https://github.com/bflad/chef-docker) to setup docker containers.
I believe you're looking for something like http://packer.io
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 ?
Amazon runs it's own variation of Linux which is different from the base image of this docker i.e. Ubuntu 14.04 LTS ?
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).
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).
Docker is distributed as a part of Amazon Linux
I'd love to have one of these, but for OpenResty and luvit. Lua, in other words.
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?
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.
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.
I'm sorry if I am completely missing the point of this effort.
I think you are, see:
https://news.ycombinator.com/item?id=8971353
https://news.ycombinator.com/item?id=8971353
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.
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.
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.
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.
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.
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.
> 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.
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.
I realise all this now. So do you - more so than most people as you're intimately familiar with the image.
I'm explaining the impression that it gives, rightly or wrongly, to those not as intimately familiar with it as you; those less familiar with Docker who may read through the README and come away thinking that it's ok to mix roles without appreciating the unwritten use cases you actually had in mind; those newer to Docker who have a Node app and a Ruby app and think "hey, this passenger-full image looks convenient, I'll use that" without appreciating the implications.
> It's even better than that: Redis and Memcached aren't even INSTALLED by default. Thus, no warning is needed. If you don't explicitly choose to use them, you do not pay any price.
Doesn't say that in the README, just says they're disabled. The fact they're not installed doesn't impact on the impression that's given.
I'm explaining the impression that it gives, rightly or wrongly, to those not as intimately familiar with it as you; those less familiar with Docker who may read through the README and come away thinking that it's ok to mix roles without appreciating the unwritten use cases you actually had in mind; those newer to Docker who have a Node app and a Ruby app and think "hey, this passenger-full image looks convenient, I'll use that" without appreciating the implications.
> It's even better than that: Redis and Memcached aren't even INSTALLED by default. Thus, no warning is needed. If you don't explicitly choose to use them, you do not pay any price.
Doesn't say that in the README, just says they're disabled. The fact they're not installed doesn't impact on the impression that's given.
Yes I was wrong about that last point, sorry about that.
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.
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.
* 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/
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.
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-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-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
Passenger-docker is very much in line with the idea of composable, reproducible infrastructure. Nothing in passenger-docker violates those principles.
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-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
Passenger-docker is very much in line with the idea of composable, reproducible infrastructure. Nothing in passenger-docker violates those principles.
Hey FooBarWidget,
I just wanted to thank you for all your hard work and for putting this out there for people to get up and running with Docker.
Of the videos I've watched on deploying Ruby on Rails apps with Docker, this container always gets a shoutout as an easy way to get started.
I just wanted to thank you for all your hard work and for putting this out there for people to get up and running with Docker.
Of the videos I've watched on deploying Ruby on Rails apps with Docker, this container always gets a shoutout as an easy way to get started.
Cool, I'm glad you appreciate it and good to know it's featured in videos. Can you tell me which videos? I'm not aware of anything like that.
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.
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.
[deleted]
> May as well just use a virtual machine at that point.
While this isn't true (as explained by others), I don't know why there's such dismissal in the docker community for a VM with ~zero boot time, good tools without requiring ssh (`docker cp`, `docker diff`, `docker exec`, volumes) and layers. These are good things! Of course packaging in a light-weight way is nice if you can manage that as well but it's not everything.
> Nice and composable, reproducible infrastructure.
Phusion passenger is also reproducible you're still using (the highly touted) Dockerfiles. I've no idea how you want to define composability.
While this isn't true (as explained by others), I don't know why there's such dismissal in the docker community for a VM with ~zero boot time, good tools without requiring ssh (`docker cp`, `docker diff`, `docker exec`, volumes) and layers. These are good things! Of course packaging in a light-weight way is nice if you can manage that as well but it's not everything.
> Nice and composable, reproducible infrastructure.
Phusion passenger is also reproducible you're still using (the highly touted) Dockerfiles. I've no idea how you want to define composability.
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.