3 ms·

looks like you just reinvent wheel called kubernetes (secrets, mounted volumes). Also when following http://12factor.net/ http://12factor.net/ there shouldn't b

looks like you just reinvent wheel called kubernetes (secrets, mounted volumes). Also when following http://12factor.net/ http://12factor.net/ there shouldn't be issues with production/testing

AdrianRossouw 10y ago
kubernetes seems like it could be overkill for many situations. this seems like it has fewer moving parts.
- maque_onlyverse 10y ago
  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?
  - jayjohnson 10y ago
    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-swarm-on-aws/ 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 RabbitMQ Example - https://gist.github.com/jay-johnson/2673ce4df42317667908#file-manually-deploying-a-rabbitmq-cluster-with-docker-swarm-L50 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.
- hosh 10y ago
  Kubernetes solves some things that Compose fails on. It's not that Kubernetes is overkill, but that Compose is an inadequate solution.
  - jayjohnson 10y ago
    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.
    - jayjohnson 10y ago
      So if I take a sample out of your Matsuri repo, how does this get changed as an "Overridables": https://github.com/shopappsio/matsuri/blob/f966480380b685d34e7c161fbb89ad55505cf571/lib/matsuri/kubernetes/service.rb#L6-L13 https://github.com/shopappsio/matsuri/blob/f966480380b685d34...
      - hosh 10y ago
        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.
      - hosh 10y ago
        By the way, if you want to talk over email, feel free to drop me a line at talktohosh at gmail dot com.
    - hosh 10y ago
      (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.
hosh 10y ago
Exactly!

looks like you just reinvent wheel called kubernetes (secrets, mounted volumes). Also when following http://12factor.net/ http://12factor.net/ there shouldn't be issues with production/testing

AdrianRossouw 10y ago

kubernetes seems like it could be overkill for many situations. this seems like it has fewer moving parts.

maque_onlyverse 10y ago
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?
- jayjohnson 10y ago
  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-swarm-on-aws/ 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 RabbitMQ Example - https://gist.github.com/jay-johnson/2673ce4df42317667908#file-manually-deploying-a-rabbitmq-cluster-with-docker-swarm-L50 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.
hosh 10y ago
Kubernetes solves some things that Compose fails on. It's not that Kubernetes is overkill, but that Compose is an inadequate solution.
- jayjohnson 10y ago
  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.
  - jayjohnson 10y ago
    So if I take a sample out of your Matsuri repo, how does this get changed as an "Overridables": https://github.com/shopappsio/matsuri/blob/f966480380b685d34e7c161fbb89ad55505cf571/lib/matsuri/kubernetes/service.rb#L6-L13 https://github.com/shopappsio/matsuri/blob/f966480380b685d34...
    - hosh 10y ago
      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.
    - hosh 10y ago
      By the way, if you want to talk over email, feel free to drop me a line at talktohosh at gmail dot com.
  - hosh 10y ago
    (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.

hosh 10y ago

Exactly!