okami101/blog
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 46 Wiki Activity

dev swarm draft

Browse Source
This commit is contained in:
Adrien Beaudouin
2022-02-13 23:12:49 +01:00
parent 8805966f16
commit 5e31236f4b
2 changed files with 88 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
content/_index.md
View File

@ -30,11 +30,12 @@ Fully embracing app containerization with `Docker`, from local, staging to produ
Mastering installations of properly configured `Docker Swarm` clusters with next containerized tools :
* [`GitLab`](https://about.gitlab.com/) or [`Gitea`](https://gitea.io/) coupled with [`Drone CI`](https://www.drone.io/) as both *self-hosted CI/CD* solutions,
* [`Traefik`](https://traefik.io/traefik/) as main cloud proxy with automatic service discovery and SSL configuration
* [`Portainer`](https://www.portainer.io/) as simple GUI for containers management.
* [`Portainer`](https://www.portainer.io/) as simple GUI for containers management
* [`Loki`](https://grafana.com/oss/loki/), [`Prometheus`](https://prometheus.io) and [`Jaeger`](https://www.jaegertracing.io/) as respective *logging*, *metrics* and *tracing* tools
* [`Grafana`](https://grafana.com) as perfect GUI dashboard builder for *Ops*.
* [`Grafana`](https://grafana.com) as perfect GUI dashboard builder for *Ops*
* [`GitLab`](https://about.gitlab.com/) or [`Gitea`](https://gitea.io/) coupled with [`Drone CI`](https://www.drone.io/) as both *self-hosted CI/CD* solutions
* [SonarQube](https://www.sonarqube.org/) for automatic quality code scan
I use managed [`PostgreSQL`](https://www.postgresql.org/), [`MySQL`](https://www.mysql.com/fr/), and `MSSQL` as main **SGBD**, as well as `Redis` for high performance cache/sessions management.

100
content/posts/2022-02-13-build-your-own-docker-swarm-cluster.md
View File

@ -34,27 +34,95 @@ You can of course apply this guide on any other cloud provider, but I doubt that
## Final goal 🎯
In the end of this multi-steps guide, you will have complete working development oriented cluster :
In the end of this multi-steps guide, you will have complete working production grade secured cluster, backup included, with optional monitoring and complete development CI/CD workflow.
* `Traefik`, a cloud native reverse proxy
### The stateful part for data 💾
## Cluster Architecture
For all data critical part, I choose to use **1 dedicated VPS**. We will install :
Note as this cluster will be intended for developer user with complete self-hosted CI/CD solution. So for a good cluster architecture starting point, we should at least have the following nodes :
* `PostgreSQL` as main production database
* `GlusterFS` as network filesystem
* `MySQL`, `MongoDB`, `Redis` as optional storage tools
* `Elasticsearch` that will be used for tracing storage (`Jaeger`)
* `Loki` with `Promtail` for centralized logs
* `Restic` for backups to external S3 compatible bucket
{{< alert >}}
There are many debates about using databases as docker container, but I personally prefer use managed server for better control, local on-disk performance, central backup management and easier possibility of database clustering.
Note as on the Kubernetes world, run containerized databases becomes reality thanks to [powerful operators](https://github.com/zalando/postgres-operator) that provide easy clustering. The is obviously no such things on Docker Swarm 🙈
{{< /alert >}}
### The stateless part, aka cluster 🚆
#### Cluster initialization 🌍
* `Docker Swarm` installation, **1 manager and 2 workers**
* `Traefik`, a cloud native reverse proxy with automatic service discovery and SSL configuration
* `Portainer` as simple GUI for containers management
#### Testing with some initial containerized tools ✅
* `pgAdmin` and `phpMyAdmin` as web database managers (optional)
* [`Diun`](https://crazymax.dev/diun/) (optional), very useful in order to be notified for all used images update inside your Swarm cluster
* Some demo containerized samples that will show you how simple is it to install self-hosted web apps thanks to your shiny new cluster as `redmine`, `n8n`
#### Monitoring (optional) 📈
* `Prometheus` as time series DB for monitoring, with many exporter (Node, PostgreSQL, MySQL Cadvisor, Traefik)
* `Jaeger` as *tracing* tools
* `Grafana` as GUI dashboard builder with many battery included dashboards
* Monitoring all the cluster
* Node, PostgreSQL and MySQL metrics
* Navigate through log history of all containers and data server node thanks to `Loki` like *ELK*, with LogQL
#### CI/CD Development workflow (optional) 💻
* `Gitea` as lightweight centralized control version, in case you want get out of Github / GitLab Cloud
* `Private docker registry` with minimal UI for all your custom app images that will be built on your development process and be used as based image for your production docker on cluster
* `Drone CI` as self-hosted CI/CD solution
* `SonarQube` as self-hosted quality code control
Finally, we'll finish this guide by a simple mini-app development with above CI/CD integration !
## Cluster Architecture 🏘️
Note as this cluster will be intended for developer user with complete self-hosted CI/CD solution. So for a good cluster architecture starting point, we can imagine the following nodes :
* `manager-01` : The frontal manager node, with proper reverse proxy and some management tools
* `worker-01` : A worker
* `worker-01` : A worker for your production/staging apps
* `runner-01` : An additional worker dedicated to CI/CD pipelines execution
* `data-01` : The critical data node, with attached and resizable volume for better flexibility
cpx11 (AMD) = 2C/2G/40Go = 4.79
cx21 (Intel) = 3C/4G/80Go = 5.88
cpx21 (AMD) = 3C/4G/80Go = 8.28
cx31 (Intel) = 2C/8G/160Go = 10.68
cpx31 (AMD) = 4C/8G/160Go = 14.88
{{< alert >}}
For a simple production cluster, you can start with only `manager-01` and `data-01` as absolutely minimal start.
For a development perspective, you can skip `worker-01` and use `manager-01` for production running.
You have plenty choices here according to your budget !
{{< /alert >}}
* Front CPX31
* Worker CPX21
* Runner CPX11
* Data CPX21 + 50Go Volume 2.40$
* Block storage 75Go FREE on Scaleway
### Hetzner VPS 🖥️
Total : 2.40 + 2*8.28 + 1*4.79 + 1*10.68 = 34.43€
Here some of the cheapest VPS options we have :
* **CPX11 (AMD)** = 2C/2G/40Go = **€4.79**
* **CX21 (Intel)** = 3C/4G/80Go = **€5.88**
* **CPX21 (AMD)** = 3C/4G/80Go = **€8.28**
My personal choice for a good balance between cheap and well-balanced cluster :
* `manager-01` : **CX21**, I'll privilege RAM
* `runner-01` : **CPX11**, 2 powerful core is better for building
* `worker-01` and `data-01` : **CX21 VS CPX21** (just a power choice matter)
We'll take additional volume of **60 Go** for **€2.88**
We finally arrive to following respectable budget range : **€25.31** - **$31.31**
The only difference being choice between **Xeon VS EPIC** as CPU power for `worker` and `data` nodes, which will our main production application nodes. A quick [sysbench](https://github.com/akopytov/sysbench) will indicates around **70-80%** more power for AMD (test date from 2022-02).
Choose wisely according to your needs.
If you don't need of `worker` and `runner` nodes, with only one simple standalone docker host without Swarm mode, you can even go down to **€14,64** with only **2 CX21** in addition to volume.
{{< alert >}}
If you intend to have your own self-hosted GitLab for an enterprise grade CI/CD workflow, you should run it on node with **8 GB** of RAM.
**4 GB** is doable if you run just one single GitLab container on it with Prometheus mode disabled and external PostgreSQL.
{{< /alert >}}