У вас есть кластер, в котором хочется разместить как можно больше рабочих сервисов и продуктов для внутреннего использования, ибо удобно: систему управления версиями, репозиторий Docker-образов, S3-хранилище, базы данных, тестовые среды и т.д. Но есть "но": многие из них, как например, репозиторий Docker-образов, могут работать только с использованием TLS. У вас есть два пути: получить сертификат от одного из сертификационных центров, платных или бесплатных, вроде Let's Encrypt, или сгенерировать самому. Устанавливать на каждого клиента сертификат нашего "левого" самопровозглашённого центра не хочется, поэтому самоподписанный сертификат отпадает. Денег платить каждый год не хочется, поэтому выбираем Let's Encrypt. Но и тут есть проблема (помимо необходимости автоматизации перевыпуска сертификата не реже раза в три месяца): внутренние сервисы нельзя выставлять в публичную сеть, а значит и HTTP-01 вариант подтверждения владения доменом нам недоступен. Остаётся только DNS-01 метод, который имеет свои подводные камни.

В данной статье я расскажу о своём опыте автоматизации выпуска/перевыпуска wildcard-сертификата для домена второго уровня (wildcard, чтобы два раза не вставать, но можно выпускать сертификаты и для каждого отдельного поддомена) для использования внутренними сервисами, расположенными в Kubernetes-кластере, с помощью cert-manager и бесплатного сервиса поддержки DNS-зон Яндекс.Коннект.

Я продолжаю цикл статей по приручению домашнего сервера разработчика, который хочет уметь в DevOps. В первой своей статье я рассказал о развёртывании Xen Project гипервизора и миграции Windows-виртуалок из Hyper-V. Во второй о развёртывании на базе виртуалок этого сервера Kubernetes-кластера. Перед написанием данной я ставил перед собой следующие цели:

1. Развернуть тестовый сайт, состоящий из статических ресурсов и front-end API в vanila Kubernetes-кластере.

2. Обеспечить доступ к этому сайту с использованием NGINX Ingress Controller.

3. Сайт должен быть доступен по HTTPS-протоколу с автоматически обновляемым TLS-сертификатом Let’s Encrypt.

Дано: домашний сервер под управлением Debian 11 с установленным гипервизором Xen.

Требуется: развернуть Kubernetes-кластер для получения опыта, связанного с настройкой и управлением Kubernetes-кластера, и дальнейшего его использования для разработки и хостинга персональных проектов.

Развёртывание Debian и Xen, а также миграция с Hyper-V на Xen нескольких Windows-виртуальных машин описана в моей статье Миграция домашнего сервера с Hyper-V на Xen Project на Debian. В ней также описана конфигурация моей сети.

В данной статье я исхожу из того, что читатель имеет представление о том, что такое Kubernetes, как он работает, из каких компонентов состоит и знаком с необходимой терминологией. Многие идеи и код я брал из статьи Разворачиваем среду для работы с микросервисами. Часть 1 установка Kubernetes HA на bare metal (Debian), но местами адаптировал под свои нужды и окружение. Задача данной статьи дать читателям готовое решение, требующее минимальных усилий для повторения и, вместе с тем, не требующее дополнительных инструментов (вроде Ansible или Terraform), а также показать новичкам некоторые моменты работы с Linux, Kubernetes и используемыми пакетами. Повествование разбито на несколько шагов, каждый из которых заключается в запуске скрипта и нескольких ручных командах.

В данной статье я опишу свой опыт миграции домашнего сервера на гипервизоре Hyper-V, установленного на Windows Server 2012 R2, на гипервизор Xen Project 4.14, установленного на Debian 11. Я ни в коем случае не являюсь экспертом в Linux, всю свою карьеру в основном использовал операционные системы Microsoft, но времена и технологии меняются, и нужно соответствовать.

Зачем мне нужен домашний сервер? Для меня — это во многом песочница, где я могу исследовать и пробовать технологии, которые не могу потестировать на десктопе. Помимо этого, конечно, он несёт и утилитарные функции: контроллер домена, файловый сервер, хостинг для сайта моей жены, TFS-сервер (да, до сих пор, но собираюсь поменять на GitLab) и др. Всё это разложено по виртуалкам для более эффективного управления и использования ресурсов. Разворачивал я Hyper-V версию лет 7 назад, с тех пор существенных изменений не производил, однако, какое-то время назад, решил мигрировать его на Linux. Наконец-то у меня дошли руки до этого. В этой статье собран мой опыт «не совсем новичка» в Linux (ранее опыт ограничивался в основном использованием Ubuntu в WSL) и платформах виртуализации (Hyper-V, VMWare).

Для меня всё, описанное в данной статье, — прежде всего, мой практический опыт, без которого любая теория — ничто. Для новичков, думаю, подробность повествования даст хорошее понимание принципов работы с Linux.