5 ms·

Having worked with Mesos, Nomad and an in-house container scheduler, I would not pick any of them for personal projects. I've not tried Kubernetes yet but I don

Having worked with Mesos, Nomad and an in-house container scheduler, I would not pick any of them for personal projects. I've not tried Kubernetes yet but I don't think it would make me change my mind. I recently went through the infrastructure that runs my personal projects (Django, PostgreSQL, Redis, a few static sites...). I decided to go with plain Docker + Ansible. These tools give me enough automation to easily scale up or change hosting provider if I need, without introducing too much magic and complexity.

djsumdog 8y ago
I'm in the exact same boat with you. I was at a shop that used DC/OS at work, and to be fair, it's probably the easiest to get initially setup. But even a basic setup is going to be really expensive, as I discovered: https://penguindreams.org/blog/installing-mesosphere-dcos-on-small-digital-ocean-droplets/ https://penguindreams.org/blog/installing-mesosphere-dcos-on... I ended up doing what you did, having Ruby provision my machines, configure them with Ansible and deploy my docker containers (calling the Docker API from Ruby). The whole thing can be found here: https://github.com/sumdog/bee2 https://github.com/sumdog/bee2 It was a lot of work setting all that up. I should have probably just used Terraform + Ansible + docker-compose. Still, I'm glad I wrote it. I learned a lot about the complexities of running a docker infrastructure.
ngrilly 8y ago
I do the same (Docker + Ansible). I also use Docker Compose. How do you deploy new versions of your apps without downtime (start the new containers, wait for them to be ready, switch traffic to new containers, shutdown old containers)? I'm using custom Ansible scripts coupled to docker-compose but it's a bit messy and non-standard.
- nicolaslem 8y ago
  To update an app container to a new version I just run Ansible again: - docker_container: image: foo/bar:latest state: started restart_policy: always pull: yes This pulls the new version and restarts the container. The downtime is probably a second maximum. It's small enough that it is not worth the trouble of a rolling release or whatnot. It's a personal project after all, no one will complain for getting a 502 once a month :) I do not use docker-compose as I never felt the need to and I read on multiple occasions that it's meant for development only.
  - ngrilly 8y ago
    Thanks for answering! That's obviously a lot easier as is :-) I have some projects that run on a single machine, but serve multiple requests per second, and it happens we deploy multiple times per day, so we can't afford a 1 second downtime (users would notice).
  - leandot 8y ago
    Many services do not tolerate any downtimes, imagine you are processing money and you kill the process in the middle, it can be quite the pain to recover.
    - nicolaslem 8y ago
      The article and my comments are about personal side projects, not about running a business. For me this means cutting down on complexity: 80% of the features for 20% of the work. Moreover, stopping a container does not mean killing it, it sends a SIGTERM that the application catches to terminate gracefully. I would also argue that applications processing money must be able to tolerate unexpected failures. Because Kubernetes or not, servers go down, processes get killed, disks get corrupt.
      - ngrilly 8y ago
        You may have side projects which are for a small business or a non-profit, and yet requires being able to sustain multiple requests per second on a single machine. In such a setup, zero downtime deployments are necessary. Some (most) application are being able to gracefully terminate, but it doesn't solve the issue. You still need some mechanism to start the new version, wait for it to be reader, switch the new traffic to the new version, and then gracefully shutdown the old version.
      - leandot 8y ago
        Those are fair points for side projects that have no visitors, but at least for me a side project can also have quite some traffic and then even a little timeout may not be an option. Plus you get a ton of goodies by relying on k8s (or similar) - ability to do an easy rollout, rollback, blue-green deployments, partial rollout, ability to replace multiple containers together if frontend and backend containers must be in sync (a pod) etc. Just my 2 cents.

djsumdog 8y ago

I'm in the exact same boat with you. I was at a shop that used DC/OS at work, and to be fair, it's probably the easiest to get initially setup. But even a basic setup is going to be really expensive, as I discovered: https://penguindreams.org/blog/installing-mesosphere-dcos-on-small-digital-ocean-droplets/ https://penguindreams.org/blog/installing-mesosphere-dcos-on... I ended up doing what you did, having Ruby provision my machines, configure them with Ansible and deploy my docker containers (calling the Docker API from Ruby). The whole thing can be found here: https://github.com/sumdog/bee2 https://github.com/sumdog/bee2 It was a lot of work setting all that up. I should have probably just used Terraform + Ansible + docker-compose. Still, I'm glad I wrote it. I learned a lot about the complexities of running a docker infrastructure.

ngrilly 8y ago

I do the same (Docker + Ansible). I also use Docker Compose. How do you deploy new versions of your apps without downtime (start the new containers, wait for them to be ready, switch traffic to new containers, shutdown old containers)? I'm using custom Ansible scripts coupled to docker-compose but it's a bit messy and non-standard.

nicolaslem 8y ago
To update an app container to a new version I just run Ansible again: - docker_container: image: foo/bar:latest state: started restart_policy: always pull: yes This pulls the new version and restarts the container. The downtime is probably a second maximum. It's small enough that it is not worth the trouble of a rolling release or whatnot. It's a personal project after all, no one will complain for getting a 502 once a month :) I do not use docker-compose as I never felt the need to and I read on multiple occasions that it's meant for development only.
- ngrilly 8y ago
  Thanks for answering! That's obviously a lot easier as is :-) I have some projects that run on a single machine, but serve multiple requests per second, and it happens we deploy multiple times per day, so we can't afford a 1 second downtime (users would notice).
- leandot 8y ago
  Many services do not tolerate any downtimes, imagine you are processing money and you kill the process in the middle, it can be quite the pain to recover.
  - nicolaslem 8y ago
    The article and my comments are about personal side projects, not about running a business. For me this means cutting down on complexity: 80% of the features for 20% of the work. Moreover, stopping a container does not mean killing it, it sends a SIGTERM that the application catches to terminate gracefully. I would also argue that applications processing money must be able to tolerate unexpected failures. Because Kubernetes or not, servers go down, processes get killed, disks get corrupt.
    - ngrilly 8y ago
      You may have side projects which are for a small business or a non-profit, and yet requires being able to sustain multiple requests per second on a single machine. In such a setup, zero downtime deployments are necessary. Some (most) application are being able to gracefully terminate, but it doesn't solve the issue. You still need some mechanism to start the new version, wait for it to be reader, switch the new traffic to the new version, and then gracefully shutdown the old version.
    - leandot 8y ago
      Those are fair points for side projects that have no visitors, but at least for me a side project can also have quite some traffic and then even a little timeout may not be an option. Plus you get a ton of goodies by relying on k8s (or similar) - ability to do an easy rollout, rollback, blue-green deployments, partial rollout, ability to replace multiple containers together if frontend and backend containers must be in sync (a pod) etc. Just my 2 cents.