In practice, I do not consider the cloud option - it is very expensive.

In fact, there are 2 main options:

  • private cloud using Kubernetes
  • virtual machines

It is clear that if Kubernetes already exists, then it is adequate to continue using it. If it is not available, then it is not always the best option to start demanding it. But then what should we do?

As an intermediate option, I usually put the solution through Podman: an easy-to-use technology, available by default in CentOS, is well compatible with Kubernetes (there is a pod concept).

Installing the Podman:

yum -y install podman
systemctl enable --now podman.socket

touch /etc/containers/nodocker

cat >/etc/containers/registries.conf.d/docker.conf <<EOF
unqualified-search-registries = ['docker.io']
EOF

An example of launching an application in Podman:

podman pod rm home-cloud --ignore --force

podman pod create --name home-cloud \
  --publish "${NODE_IP}:${NODE_UI_PORT}:9090" \
  --publish "${NODE_IP}:${DNS_PORT}:9053" \
  --publish "${NODE_IP}:${DNS_PORT}:9053/udp" \
  --publish "${NODE_IP}:${LB_INT_WEB_PORT}:80" \
  --publish "${NODE_IP}:${LB_INT_SWEB_PORT}:443" \
  --publish "${NODE_IP}:${LB_EXT_WEB_PORT}:8080" \
  --publish "${NODE_IP}:${LB_EXT_SWEB_PORT}:8443"

podman run --pod home-cloud --name home-cloud-traefik \
  -v /cloud/engine/traefik.yml:/etc/traefik/traefik.yml \
  -v /var/run/podman/podman.sock:/var/run/docker.sock:ro \
  -d traefik
podman run --pod home-cloud --name home-cloud-dns \
  -v /cloud/engine/dnsmasq.conf:/etc/dnsmasq.conf:ro \
  -v /cloud/engine/dnsmasq.hosts:/dnsmasq.hosts:ro \
  -d 4km3/dnsmasq:2.85-r2
podman run --pod home-cloud --name home-cloud-webui \
  -v /:/host:ro \
  -v /cloud/engine:/engine:rw \
  -d nginx

Podman applications can also be run via system (workload.yaml – Kubernetes pod):

escaped=$(systemd-escape ~/workload.yaml)
systemctl --user start podman-kube@$escaped.service

Or just pod:

$ podman create --name nginx nginx:latest
$ podman generate systemd --restart-policy=always -t 1 nginx
# container-de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6.service
# autogenerated by Podman 1.8.0
# Wed Mar 09 09:46:45 CEST 2020

[Unit]
Description=Podman container-de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/var/run/container/storage

[Service]
Restart=always
ExecStart=/usr/bin/podman start de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6
ExecStop=/usr/bin/podman stop \
        -t 1 de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6
KillMode=none
Type=forking
PIDFile=/run/user/1000/overlay-containers/de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6/userdata/conmon.pid

[Install]
WantedBy=default.target

Naturally, after completing the configuration, you need to restart the virtual machine to make sure that everything starts correctly.

If we talk about Kubernetes, then Helm is suitable for the delivery of the “box”, and if the application is internal/SaaS, then Kustomize is better. The main practical difference from Helm is that Helm quite often leads releases into some kind of non-working states that need to be fixed by hand. In principle, this does not happen in Customize, because there is no such thing.