8 ms·

Wow! Did Docker give up swarm? I thought there was a time when Docker didn't like the existence of k8s all that much. Anyways, I envision this being very usefu

Wow! Did Docker give up swarm? I thought there was a time when Docker didn't like the existence of k8s all that much. Anyways, I envision this being very useful for development, may even replace my docker-compose based test setup.

frik 9y ago
Docker was in other news yesterday, though it got flagged: https://news.ycombinator.com/item?id=16074264 https://news.ycombinator.com/item?id=16074264
bboreham 9y ago
Officially, both Swarm and Kubernetes are valued features of Docker. Swarm was always much simpler to get started with, so some people will prefer it. But it's clear to me which one won.
sandGorgon 9y ago
Your docker compose yml is trivially reusable for Swarm. We run it in production and is spectacular . The complexity overhead of kubernetes may be premature when you don't have massive requirements
- pacavaca 9y ago
  That's the thing, we use k8s in production and I just used docker-compose for testing in my device environment for the sake of simplicity. Though over time it became not so simple to maintain two parallel config as the system grown up.
  - sandGorgon 9y ago
    that's one of the reason we decided to jump on swarm. And seeing how Swarm has matured and added features, we are very happy. Azure also comes with a Swarm-mode deployment template which is pretty great (https://github.com/Azure/acs-engine/blob/master/docs/swarmmode.md https://github.com/Azure/acs-engine/blob/master/docs/swarmmo...). However, setting up and running Swarm has been a pleasure.
    - StavrosK 9y ago
      This is very interesting. I've been looking for middle ground between Dokku and Kubernetes, I'll give swarm a try. Does it handle ingress at all? vhosts, TLS certificates, etc?
      - sz4kerto 9y ago
        If you're paying for EE, then UCP can do a lot for you. We're using the HRM heavily, and it's very handy.
        StavrosK 9y ago
        I don't know what any of those mean :(
        zenlikethat 9y ago
        EE = Enterprise Edition UCP = Universal Control Plane (web app to manage clusters and containers) HRM = Host routing mesh (I think). If I recall correctly, it’s used to control ingress to the cluster via virtual host routing, etc. They are paid Docker Inc. products. I worked for Docker once upon a time so I’m happy to hear there are happy customers :)
        StavrosK 9y ago
        Ah I see, thank you for clarifying! I'm not familiar with the products, but I'll research them.
        sandGorgon 9y ago
        Docker has added ingress routing in 17.06 that works at a lower level than HTTP Routing Mesh. You should try that now. Other than that, how have you found EE ? We have considered paying for it, but after seeing Docker Cloud at 15$ per node per month, we are considering switching to it.
      - sandGorgon 9y ago
  - linkmotif 9y ago
    Helm makes this easy. It’s great, just use the templating features and not the package management stuff.
    - shaftoe 9y ago
      We found the same thing after the package management stuff caused issues in prod. We rolled our own go program that just does go tpl substitution in yaml with overrides like helm. Works on charts out of the box, but instead of talking to a service, it outputs a yaml manifest ready to kubectl apply. We've thought about open sourcing it. It took us literally a day to put together and had worked without flaw for 8 months in production.
      - linkmotif 9y ago
        Cool! I just don't use the package management stuff. My workflow also has local manifest template rendering, but I use helm-template[0]. My chart is just a local directory, not a package or anything. Then, to release: * Render the chart and run it through kube-cloud-build[1] to make sure my containers are all built before I deploy: `helm template /path/to/chart | kube-cloud-build -r repo` * Deploy with helm: `helm upgrade RELEASE_NAME /path/to/chart` Has been working really well for me. [0] https://github.com/technosophos/helm-template https://github.com/technosophos/helm-template [1] https://github.com/dminkovsky/kube-cloud-build https://github.com/dminkovsky/kube-cloud-build
sz4kerto 9y ago
No, it didn't. Yes, k8s has 'won' in large-scale deployments, but if you're working at a small shop, then just imitating what Google does with millions of servers is dumb. Do what works at your scale -- and Swarm is extremely easy to manage. Many people ask why would someone use an orchestrator on a small cluster (dozens of hosts). Why not? Swarm is very easy to manage and maintain, using Puppet or Ansible is not less complicated at all. The future of Docker, Inc. is of course Docker EE, and the future of Docker EE is _not_ the scheduler, it's everything around it.
- xorcist 9y ago
  > Swarm is very easy to manage and maintain, using Puppet or Ansible is not less complicated The idea that dockerized software somehow is less dependent on configuration management seems to be a popular and completely misguided one. The two trends are completely separate, but I would argue from experience that unless you have absolutely nailed the configuration and integration of all your moving parts, don't even look at containers yet. Containers tend to lead to more moving parts, not less. And unless you know how to configure them, and perhaps even more importantly how to test them, that will only make matters worse.
  - sz4kerto 9y ago
    No, it's not 'less dependent'. The way how it helps is that you can standardize configuration management across environments relatively easily. Containerization does not result in less moving parts in a given environment; but it does result in less moving parts across the whole development flow (from a developer laptop to a production cluster).
  - kuschku 9y ago
    Thanks to CoreOS containerLinux, you don’t really need Puppet or Ansible. You specify your Ignition config, and just drop it as a tiny partition on the servers, and drop the OS onto a separate, adjecent partition, and then have local storage even separately. Commonly you use PXE to avoid having these locally. Then everything you do on top of that is handled by the container scheduler, and your containers.

frik 9y ago

Docker was in other news yesterday, though it got flagged: https://news.ycombinator.com/item?id=16074264 https://news.ycombinator.com/item?id=16074264

bboreham 9y ago

Officially, both Swarm and Kubernetes are valued features of Docker. Swarm was always much simpler to get started with, so some people will prefer it. But it's clear to me which one won.

sandGorgon 9y ago

Your docker compose yml is trivially reusable for Swarm. We run it in production and is spectacular . The complexity overhead of kubernetes may be premature when you don't have massive requirements

pacavaca 9y ago
That's the thing, we use k8s in production and I just used docker-compose for testing in my device environment for the sake of simplicity. Though over time it became not so simple to maintain two parallel config as the system grown up.
- sandGorgon 9y ago
  that's one of the reason we decided to jump on swarm. And seeing how Swarm has matured and added features, we are very happy. Azure also comes with a Swarm-mode deployment template which is pretty great (https://github.com/Azure/acs-engine/blob/master/docs/swarmmode.md https://github.com/Azure/acs-engine/blob/master/docs/swarmmo...). However, setting up and running Swarm has been a pleasure.
  - StavrosK 9y ago
    This is very interesting. I've been looking for middle ground between Dokku and Kubernetes, I'll give swarm a try. Does it handle ingress at all? vhosts, TLS certificates, etc?
    - sz4kerto 9y ago
      If you're paying for EE, then UCP can do a lot for you. We're using the HRM heavily, and it's very handy.
      - StavrosK 9y ago
        I don't know what any of those mean :(
        zenlikethat 9y ago
        EE = Enterprise Edition UCP = Universal Control Plane (web app to manage clusters and containers) HRM = Host routing mesh (I think). If I recall correctly, it’s used to control ingress to the cluster via virtual host routing, etc. They are paid Docker Inc. products. I worked for Docker once upon a time so I’m happy to hear there are happy customers :)
        StavrosK 9y ago
        Ah I see, thank you for clarifying! I'm not familiar with the products, but I'll research them.
        sandGorgon 9y ago
        Docker has added ingress routing in 17.06 that works at a lower level than HTTP Routing Mesh. You should try that now. Other than that, how have you found EE ? We have considered paying for it, but after seeing Docker Cloud at 15$ per node per month, we are considering switching to it.
    - sandGorgon 9y ago
- linkmotif 9y ago
  Helm makes this easy. It’s great, just use the templating features and not the package management stuff.
  - shaftoe 9y ago
    We found the same thing after the package management stuff caused issues in prod. We rolled our own go program that just does go tpl substitution in yaml with overrides like helm. Works on charts out of the box, but instead of talking to a service, it outputs a yaml manifest ready to kubectl apply. We've thought about open sourcing it. It took us literally a day to put together and had worked without flaw for 8 months in production.
    - linkmotif 9y ago
      Cool! I just don't use the package management stuff. My workflow also has local manifest template rendering, but I use helm-template[0]. My chart is just a local directory, not a package or anything. Then, to release: * Render the chart and run it through kube-cloud-build[1] to make sure my containers are all built before I deploy: `helm template /path/to/chart | kube-cloud-build -r repo` * Deploy with helm: `helm upgrade RELEASE_NAME /path/to/chart` Has been working really well for me. [0] https://github.com/technosophos/helm-template https://github.com/technosophos/helm-template [1] https://github.com/dminkovsky/kube-cloud-build https://github.com/dminkovsky/kube-cloud-build

sz4kerto 9y ago

No, it didn't. Yes, k8s has 'won' in large-scale deployments, but if you're working at a small shop, then just imitating what Google does with millions of servers is dumb. Do what works at your scale -- and Swarm is extremely easy to manage. Many people ask why would someone use an orchestrator on a small cluster (dozens of hosts). Why not? Swarm is very easy to manage and maintain, using Puppet or Ansible is not less complicated at all. The future of Docker, Inc. is of course Docker EE, and the future of Docker EE is _not_ the scheduler, it's everything around it.

xorcist 9y ago
> Swarm is very easy to manage and maintain, using Puppet or Ansible is not less complicated The idea that dockerized software somehow is less dependent on configuration management seems to be a popular and completely misguided one. The two trends are completely separate, but I would argue from experience that unless you have absolutely nailed the configuration and integration of all your moving parts, don't even look at containers yet. Containers tend to lead to more moving parts, not less. And unless you know how to configure them, and perhaps even more importantly how to test them, that will only make matters worse.
- sz4kerto 9y ago
  No, it's not 'less dependent'. The way how it helps is that you can standardize configuration management across environments relatively easily. Containerization does not result in less moving parts in a given environment; but it does result in less moving parts across the whole development flow (from a developer laptop to a production cluster).
- kuschku 9y ago
  Thanks to CoreOS containerLinux, you don’t really need Puppet or Ansible. You specify your Ignition config, and just drop it as a tiny partition on the servers, and drop the OS onto a separate, adjecent partition, and then have local storage even separately. Commonly you use PXE to avoid having these locally. Then everything you do on top of that is handled by the container scheduler, and your containers.