3 ms·

Shipping applications. Also, building. Lets say I have a web app - and there's a production server which runs in docker. Cool! Some port-forwarding easiness wi

Shipping applications. Also, building. Lets say I have a web app - and there's a production server which runs in docker. Cool! Some port-forwarding easiness with nginx or your favorite flavor of X and it's good to go. When you want to upgrade, you run your integration tests on the new container. To "Ship" you just, well, change the port forward once you confirm it's good. If you want to change it to an entirely new server - easy. Just pull your image and create your container - then change your IP information to point to the new server. Docker is to contain things, not necessarily for security, but to make a build contained. Make it have no dependencies outside the container, other than being able to run Docker.

GrinningFool 13y ago
I've been running into this line of thought quite a bit as I explore containers, but nowhere is it addressed how contained applications talk to each other. An app seldom lives on its own - it will integrate databases, API calls into other systems, etc - how are those configured reliably and correctly when in such a transient environment? Are they also containers? If so, how are they discovered? Dynamic configuration generation or does the application have to be aware of how to discover them at runtime? What about in a dev environment? It seems that configuration on a single local host would look vastly different, in spite of the same code running.
- simonw 13y ago
  If you read through the redis service example it might answer some of your questions: http://docs.docker.io/en/latest/examples/running_redis_service/ http://docs.docker.io/en/latest/examples/running_redis_servi... It shows how a container can be "linked" to another container with an alias, and that alias then causes environment variables within the container to point to the correct IP address and port: DB_NAME=/violet_wolf/db DB_PORT_6379_TCP_PORT=6379 DB_PORT=tcp://172.17.0.33:6379 DB_PORT_6379_TCP=tcp://172.17.0.33:6379 DB_PORT_6379_TCP_ADDR=172.17.0.33 DB_PORT_6379_TCP_PROTO=tcp
  - GrinningFool 13y ago
    Cool, thanks for the link.
MartinMond 13y ago
Can you explain that further? I don't get it at all. No application is that simple. You need services that persist between deployments. Like a database. So you make the database run in it's own container and have the containers talk. Now you want to upgrade the database. How do you do that? So you have some persistent storage that can be attached to the containers. Now you create a new container that has all the exact knowledge (in the form of ad-hoc scripts?) that it's job is to get the attached volume and upgrade the data there and then run the new version of the database? How is that more convenient or in any way better than chef or puppet?
- nickstinemates 13y ago
  Data migrations are tricky no matter what technology you apply to automate them. Also, there is no real animosity or conflicting choice between Chef/Puppet and Docker. While there's overlap, there's nothing preventing you from taking the best of both technologies and integrating them. In fact, there are projects (like deis.io) which attempt to do just that. I have written about how to do basic data migrations with Docker. You can find the link in my profile.
  - MartinMond 13y ago
    First off Sorry, I didn't want to imply that there's any animosity or conflict between Chef/Puppet and Docker. I don't think there is any? Also I completely agree that data migrations are tricky, that's why I need a tool to help me there as best as possible. I should have asked: Given that I'm familiar with or can learn Chef/Puppet what advantage do I get from (also) using Docker. Or what advantage will I get down the road from (also) using Docker? For example limiting resources come to mind, giving the processes in the container different IO priorities, memory allowances etc. But that's all just cgroup settings, I can do that without creating a container (via Docker) for individual processes. I just don't see any situation where a Docker container is more useful than a Chef/Puppet recipe. And for any "complicated" setup I feel the advanced features of Chef/Puppet that allow me to fine-tune the setup for each deployment make up for the ease of use of Docker. Yet there's a huge amount of buzz around Docker and containerization in general. What am I missing?

GrinningFool 13y ago

I've been running into this line of thought quite a bit as I explore containers, but nowhere is it addressed how contained applications talk to each other. An app seldom lives on its own - it will integrate databases, API calls into other systems, etc - how are those configured reliably and correctly when in such a transient environment? Are they also containers? If so, how are they discovered? Dynamic configuration generation or does the application have to be aware of how to discover them at runtime? What about in a dev environment? It seems that configuration on a single local host would look vastly different, in spite of the same code running.

simonw 13y ago
If you read through the redis service example it might answer some of your questions: http://docs.docker.io/en/latest/examples/running_redis_service/ http://docs.docker.io/en/latest/examples/running_redis_servi... It shows how a container can be "linked" to another container with an alias, and that alias then causes environment variables within the container to point to the correct IP address and port: DB_NAME=/violet_wolf/db DB_PORT_6379_TCP_PORT=6379 DB_PORT=tcp://172.17.0.33:6379 DB_PORT_6379_TCP=tcp://172.17.0.33:6379 DB_PORT_6379_TCP_ADDR=172.17.0.33 DB_PORT_6379_TCP_PROTO=tcp
- GrinningFool 13y ago
  Cool, thanks for the link.

MartinMond 13y ago

Can you explain that further? I don't get it at all. No application is that simple. You need services that persist between deployments. Like a database. So you make the database run in it's own container and have the containers talk. Now you want to upgrade the database. How do you do that? So you have some persistent storage that can be attached to the containers. Now you create a new container that has all the exact knowledge (in the form of ad-hoc scripts?) that it's job is to get the attached volume and upgrade the data there and then run the new version of the database? How is that more convenient or in any way better than chef or puppet?

nickstinemates 13y ago
Data migrations are tricky no matter what technology you apply to automate them. Also, there is no real animosity or conflicting choice between Chef/Puppet and Docker. While there's overlap, there's nothing preventing you from taking the best of both technologies and integrating them. In fact, there are projects (like deis.io) which attempt to do just that. I have written about how to do basic data migrations with Docker. You can find the link in my profile.
- MartinMond 13y ago
  First off Sorry, I didn't want to imply that there's any animosity or conflict between Chef/Puppet and Docker. I don't think there is any? Also I completely agree that data migrations are tricky, that's why I need a tool to help me there as best as possible. I should have asked: Given that I'm familiar with or can learn Chef/Puppet what advantage do I get from (also) using Docker. Or what advantage will I get down the road from (also) using Docker? For example limiting resources come to mind, giving the processes in the container different IO priorities, memory allowances etc. But that's all just cgroup settings, I can do that without creating a container (via Docker) for individual processes. I just don't see any situation where a Docker container is more useful than a Chef/Puppet recipe. And for any "complicated" setup I feel the advanced features of Chef/Puppet that allow me to fine-tune the setup for each deployment make up for the ease of use of Docker. Yet there's a huge amount of buzz around Docker and containerization in general. What am I missing?