5 ms·

For personal projects I am using multi-node Hetzner instances managed with a Terraform script heavily inspired from https://github.com/hobby-kube/guide https://

For personal projects I am using multi-node Hetzner instances managed with a Terraform script heavily inspired from https://github.com/hobby-kube/guide https://github.com/hobby-kube/guide + RKE for K8S setup and it works really well.

hobofan 8y ago
For personal projects, I am using a single dedicated server at Hetzner with Docker & HAProxy. It's beefy enough to be able to handle as many personal projects as I have time to dedicate to. I've tried to replace my Docker setup with Kubernetes multiple, but it was always too much of a hassle. Things that were easy with a "bare" Docker setup became hard, and single-node clusters always felt like a second-class citizen.
- ngrilly 8y ago
  I almost do the same (Docker and nginx as a reverse proxy on Google Compute Engine or Digital Ocean virtual machines). But how do you manage deployments of new versions without downtime? I use Docker Compose, but I had to complete it with some scripts to manage the deployment (start the new containers, wait for new containers to be ready, switch traffic to new containers, shutdown old containers), and it's a bit messy and non-standard. I'm thinking of using using Docker in swarm mode which offers the concept of services with automated deployments.
  - leandot 8y ago
    I would not recommend Docker Swarm, it's way too simplistic and my feeling is that it lags so much behind k8s that it might get discontinued. I've done Ansible, Docker Swarm, custom scripts and nothing is as clean as using standard K8S components + it gives you a good skill on your resume.
    - ngrilly 8y ago
      I'm afraid too of a discontinuation of Docker swarm mode... And agreed about having Kubernetes on your resume being a good thing.
    - GordonS 8y ago
      Is Docker Swarm really too simple for personal projects?
      - leandot 8y ago
        Depends on what you call a personal project, it might even be an overkill for some. My problem with it is that it does not seem to be as actively developed and gaining traction as other alternatives and support for it might get removed in the future. That is only an assumption though, I've used it before and it is much easier to start with than k8s. For really simple cases what worked well was to use docker-machine to provision a remote host. When developing I'd use the local docker, for production I'd switch the active docker to the remote host via docker-machine and just use docker-compose to bring a container up and down.
  - hobofan 8y ago
    > But how do you manage deployments of new versions without downtime? I don't try to have 100% uptime. For most projects I will usually have a few seconds to a minute of downtime when deploying (as long as it takes the docker container to start). When I try to minimize the downtime below that, I spin up a second container in parallel, change the HAProxy address to that and reload HAProxy, which gives zero-downtime (with small caveats). For most scenarios (including business) I've found that to be a reasonable approach. Most businesses can live with that kind of downtime, and trying to achieve less downtime becomes unproportionally more expensive.

hobofan 8y ago

For personal projects, I am using a single dedicated server at Hetzner with Docker & HAProxy. It's beefy enough to be able to handle as many personal projects as I have time to dedicate to. I've tried to replace my Docker setup with Kubernetes multiple, but it was always too much of a hassle. Things that were easy with a "bare" Docker setup became hard, and single-node clusters always felt like a second-class citizen.

ngrilly 8y ago
I almost do the same (Docker and nginx as a reverse proxy on Google Compute Engine or Digital Ocean virtual machines). But how do you manage deployments of new versions without downtime? I use Docker Compose, but I had to complete it with some scripts to manage the deployment (start the new containers, wait for new containers to be ready, switch traffic to new containers, shutdown old containers), and it's a bit messy and non-standard. I'm thinking of using using Docker in swarm mode which offers the concept of services with automated deployments.
- leandot 8y ago
  I would not recommend Docker Swarm, it's way too simplistic and my feeling is that it lags so much behind k8s that it might get discontinued. I've done Ansible, Docker Swarm, custom scripts and nothing is as clean as using standard K8S components + it gives you a good skill on your resume.
  - ngrilly 8y ago
    I'm afraid too of a discontinuation of Docker swarm mode... And agreed about having Kubernetes on your resume being a good thing.
  - GordonS 8y ago
    Is Docker Swarm really too simple for personal projects?
    - leandot 8y ago
      Depends on what you call a personal project, it might even be an overkill for some. My problem with it is that it does not seem to be as actively developed and gaining traction as other alternatives and support for it might get removed in the future. That is only an assumption though, I've used it before and it is much easier to start with than k8s. For really simple cases what worked well was to use docker-machine to provision a remote host. When developing I'd use the local docker, for production I'd switch the active docker to the remote host via docker-machine and just use docker-compose to bring a container up and down.
- hobofan 8y ago
  > But how do you manage deployments of new versions without downtime? I don't try to have 100% uptime. For most projects I will usually have a few seconds to a minute of downtime when deploying (as long as it takes the docker container to start). When I try to minimize the downtime below that, I spin up a second container in parallel, change the HAProxy address to that and reload HAProxy, which gives zero-downtime (with small caveats). For most scenarios (including business) I've found that to be a reasonable approach. Most businesses can live with that kind of downtime, and trying to achieve less downtime becomes unproportionally more expensive.