looks like you just reinvent wheel called kubernetes (secrets, mounted volumes). Also when following http://12factor.net/ there shouldn't be issues with production/testing
well, when I see someone playing `sed` on yml file - I'm out. If you are looking for simpler approach, why just not run docker with passing env, or mount volume with those information which image need?
Agreed. That's a great point when it is a simple use case, and how I started. Now that I build for Docker Compose out of the gate, it allows me to deploy a composition across a multi-host Docker Swarm (usually just changing the network driver to overlay + utilize labels) with 1 command, and more importantly I do not have to rebuild my container on production. Back in docker 1.9, I found myself running too many variations to get the same behavior that Compose natively handles with the new labels + overlay functionality (reference http://blog.levvel.io/blog-post/running-distributed-docker-s...). I was using `docker run` to deploy across specific hosts using manually-assigned env vars invoked with a docker run:
# docker run -itd --name=AppDeployedToNode1 --env="constraint:node==swarm1.internallevvel.com" busybox
# docker run -itd --name=AppDeployedToNode2 --env="constraint:node==swarm2.internallevvel.com" busybox
# docker run -itd --name=AppDeployedToNode3 --env="constraint:node==swarm3.internallevvel.com" busybox
Looking back I feel like it was a lot of effort to deploy 3 busybox instances or that initial RabbitMQ cluster…and that effort to handle the “production deployment case” as early as possible is what set me on the path to the new Docker Compose-centric approach discussed in the link above.
I am pretty new kubernetes. What are some of the gaps with docker compose vs kube's deployment orchestration? I am pretty happy with docker 1.10.3, but am always interested in hearing about something better/cleaner (I don't know what I don't know). I'm looking over your github for some samples at the moment.
let() is define a memoized method. When you inherit or include that module into a new class, you can redefine that same let() and the new class will use the redefined method instead of what is inherited. You can do that with any of the let() that gets defined. This lets you use as much or as little of the shared code that you want.
(1) Kubernetes pods share the same ip address. This one is huge, in that it means I am not address containers by port, but by ip address. A single pod is a collection of containers, much like a single unit of compose.yml where things can be linked together.
(2) Building on (1), SkyDNS allows pods to be named.
(3) Building on (2), we can define Services that are dynamically selected from pods. That means if I have a pod that depends on another pod, I can instead have it depend upon a Service. The individual pods that make up the Service can come up or go down, allowing updates and maintenance to be decoupled.
Those are the basics. Note that, I remember seeing a presentation from the Docker folks debating whether they should implement something like this. The idea is too useful not to use.
This is sufficiently useful to run a single-node kubelet on your dev machine instead of using Docker Compose on your dev machine. Compose will still be OK if you are only working with a single microservice/app. When that n > 1, that's when the pods and services of K8S start making a lot more sense.
Agreed. It is not a good idea to store the db user/password in a docker-compose.yml file, but it is nice for demonstrating with a container that's more than a "hello world" + non-production use cases.
Please add a description to your code. Yes, we can read the source, but at least a few sentences about what your work is about and what it will do will motivate many more people to take a closer look. Adding good docs values your own work!
You are right in that adding good doc adds value to my work. However, there are a lot of other things I need to do, and the value of those outweighs the value of documenting this code.
Besides, that code doesn't make sense without an example. The best example is locked behind proprietary code. Feel free to ping me if you want me to walk you through what it is about.
Ah, so you are that one guy on the internet that has so many other things to do, nice to meet you!
It is not about time. We have 24 hours every day, everyone has lots of things to do.
If I could read just one or two sentences describing what your code does, I had at least some basic information to consider if it is worth spending some time on this.
As there is nothing and you think it is a waste of time to document that code, why should I spend my time with some code that you think is a waste of time to document?
WARNING that compose file gives the container ALL, SYS_ADMIN and NET_ADMIN capabilities, effectively giving it root on your machine. Doing that for some random image seems like a very bad idea.
I totally agree and this is not a great idea for new comers. I do find it easier to debug things with all the bells and whistles turned on, but yea the CAP adds are NOT production ready. I will remove them to prevent confusion for those looking to get started with docker.
Database choice: MySQL over Oracle or PostreSQL: suboptimal due to silent data corruption issues and lack of OS authentication mechanism in MySQL.
Database provisioning: why not implement a generic createdb(1M) program with required command line switches which OS packages delivering the required filesystem structures could call in their postinstall phase? I wrote such a program (for Oracle DB) in shell and AWK and it works great for all sorts of OS configuration packages which create all kinds of databases; it makes Docker completely unnecessary, not to mention superflouous;
Substrate choice: what techical advantages does Docker provide over imgadm(1M) and zones built into SmartOS ("people might be more familiar with Linux and Docker" is not a technical advantage)?
These are great points, but with the post I wanted to share how I approach designing and building docker containers, because I hope it saves others time building them. When I started trying to deploy containers on production without Docker Compose it was painful. Now that I know what that time sink feels like, I try to focus on using configuration management during initialization inside the container instead of at the Dockerfile RUN directive (which requires a rebuild).
Back to your points, can I ask if you are interested in using this container approach to build a database container cluster in docker and then benchmark against a working imgadm(1M) + SmartOS environment? From the docker-side when I scale out a cluster of database runtime-only containers, I utilize the volume mounting attribute that is commented out in the repo's compose file (https://github.com/jay-johnson/docker-schema-prototyping-wit...) and then host the database files outside of the containers in a persistent storage location that is mounted + available on the hosts where the docker containers are running. As for building the database container for this proposed solution I would still utilize this Docker Compose-centric approach in development and then in production because I can build the container one time and not deal with a rebuild which invalidates testing a container within my DevOps artifact pipeline.
Wrapping up, I live more on the application development side so I cannot speak specifically to SmartOS or imgadm(1M), but I know the docker documentation and community are pretty helpful for getting/finding technical solutions that helped me build + launch products (go team!). If you are interested we can discuss more details about how I would approach bench marking these two database environments. I am a big proponent of testing everything and I would enjoy discussing how to tackle a db perf/load/ha + test harness like my message simulator (https://github.com/GetLevvel/message-simulator).
25 comments
[ 3.1 ms ] story [ 65.7 ms ] threadthis seems like it has fewer moving parts.
# docker run -itd --name=AppDeployedToNode1 --env="constraint:node==swarm1.internallevvel.com" busybox
# docker run -itd --name=AppDeployedToNode2 --env="constraint:node==swarm2.internallevvel.com" busybox
# docker run -itd --name=AppDeployedToNode3 --env="constraint:node==swarm3.internallevvel.com" busybox
RabbitMQ Example - https://gist.github.com/jay-johnson/2673ce4df42317667908#fil...
Looking back I feel like it was a lot of effort to deploy 3 busybox instances or that initial RabbitMQ cluster…and that effort to handle the “production deployment case” as early as possible is what set me on the path to the new Docker Compose-centric approach discussed in the link above.
(2) Building on (1), SkyDNS allows pods to be named.
(3) Building on (2), we can define Services that are dynamically selected from pods. That means if I have a pod that depends on another pod, I can instead have it depend upon a Service. The individual pods that make up the Service can come up or go down, allowing updates and maintenance to be decoupled.
Those are the basics. Note that, I remember seeing a presentation from the Docker folks debating whether they should implement something like this. The idea is too useful not to use.
This is sufficiently useful to run a single-node kubelet on your dev machine instead of using Docker Compose on your dev machine. Compose will still be OK if you are only working with a single microservice/app. When that n > 1, that's when the pods and services of K8S start making a lot more sense.
In other words, a Dockerfile specifies what you want to build, and a compose file specifies how you will run it.
I had tried Compose in a previous incarnation of Matsuri, but Compose has flaws in it that Kubernetes solves.
Besides, that code doesn't make sense without an example. The best example is locked behind proprietary code. Feel free to ping me if you want me to walk you through what it is about.
It is not about time. We have 24 hours every day, everyone has lots of things to do.
If I could read just one or two sentences describing what your code does, I had at least some basic information to consider if it is worth spending some time on this.
As there is nothing and you think it is a waste of time to document that code, why should I spend my time with some code that you think is a waste of time to document?
Anyway, have a nice day!
OP why are these needed? Can you remove them?
Database provisioning: why not implement a generic createdb(1M) program with required command line switches which OS packages delivering the required filesystem structures could call in their postinstall phase? I wrote such a program (for Oracle DB) in shell and AWK and it works great for all sorts of OS configuration packages which create all kinds of databases; it makes Docker completely unnecessary, not to mention superflouous;
Substrate choice: what techical advantages does Docker provide over imgadm(1M) and zones built into SmartOS ("people might be more familiar with Linux and Docker" is not a technical advantage)?
Back to your points, can I ask if you are interested in using this container approach to build a database container cluster in docker and then benchmark against a working imgadm(1M) + SmartOS environment? From the docker-side when I scale out a cluster of database runtime-only containers, I utilize the volume mounting attribute that is commented out in the repo's compose file (https://github.com/jay-johnson/docker-schema-prototyping-wit...) and then host the database files outside of the containers in a persistent storage location that is mounted + available on the hosts where the docker containers are running. As for building the database container for this proposed solution I would still utilize this Docker Compose-centric approach in development and then in production because I can build the container one time and not deal with a rebuild which invalidates testing a container within my DevOps artifact pipeline.
Wrapping up, I live more on the application development side so I cannot speak specifically to SmartOS or imgadm(1M), but I know the docker documentation and community are pretty helpful for getting/finding technical solutions that helped me build + launch products (go team!). If you are interested we can discuss more details about how I would approach bench marking these two database environments. I am a big proponent of testing everything and I would enjoy discussing how to tackle a db perf/load/ha + test harness like my message simulator (https://github.com/GetLevvel/message-simulator).
Feel free to connect with me on LinkedIn anytime: https://www.linkedin.com/in/jay-johnson-27a68b8a
vmadm(1M) provisioning can take anywhere from 5 to 25 seconds.
Oracle DB provisioning with my program takes 45 minutes, as it performs a CREATE DATABASE and is constant irrespective of hardware.