📝 Почтовый сервер с нуля. Часть 3

Михаил, DevOps-инженер из Nixys, завершает серию статей про создание почтового сервера с чистого поля.

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

P.S.: первая и вторая части — по ссылкам.

#Хабр #статья_Nixys #devops #почтовыйсервер

Делимся полезным постом от @DevOpsKaz*👩‍💻 *Основные команды Kubernetes для восстановления после сбоев, которые помогают в 99% случаев:

kubectl get pods \-\-all\-namespaces Проверить статус всех подов во всех неймспейсах, чтобы найти сбои.

kubectl describe pod pod_name Получить подробную информацию о неудачном поде.

kubectl logs pod_name \-c container_name Просмотреть логи конкретного контейнера в поде для устранения проблем.

kubectl get events \-\-all\-namespaces \-\-sort\-by='.metadata.creationTimestamp Просмотреть последние события для нахождения ошибок и сбоев.

kubectl get nodes Проверить статус нод в кластере и выявить возможные сбои на нодах.

kubectl drain node_name \-\-ignore\-daemonsets Безопасно эвакуировать и изолировать ноду для восстановления.

kubectl cordon node_name Пометить ноду как недоступную для планирования новых подов во время восстановления.

kubectl delete pod pod_name \-\-grace\-period=0 \-\-force Принудительно удалить сбойный под, чтобы перезапустить его или освободить ресурсы для восстановления.

kubectl rollout undo deployment deployment_name Откатить деплоймент, если новый релиз вызывает сбои.

kubectl exec \-it pod_name \-\- /bin/sh Получить доступ к контейнеру для отладки и решения проблем прямо внутри пода.

kubectl get componentstatuses Проверить здоровье ключевых компонентов кластера, таких как etcd и kube-apiserver.

kubectl top nodes Мониторить использование ресурсов нод, чтобы выявить проблемы с исчерпанием ресурсов.

kubectl top pods \-\-all\-namespaces Проверить использование ресурсов подов во всех неймспейсах для выявления узких мест.

kubectl delete node node_name Удалить неработающую ноду из кластера для восстановления.

etcdctl \-\-endpoints=https://etcd\-server:2379 snapshot restore backup.db Восстановить etcd из снимка в случае сбоя.

kubectl apply \-f backup.yaml Применить конфигурации из резервной копии во время восстановления.

kubectl taint nodes node_name key=value Запретить планирование подов на ноду, которая имеет проблемы, в процессе восстановления.

kubectl get endpoints service_name Проверить конечные точки сервиса, чтобы убедиться в их корректной работе во время восстановления.

*😛*** #партнёрский_пост

👩‍💻 Всем DevOps! Начнём неделю с подборки лучших практик по Terraform:

1. Разделяйте файлы конфигураций. Вместо того чтобы помещать весь код в main.tf, лучше распределите его по нескольким файлам:
   • main.tf: вызывает модули, локальные файлы и источники данных для создания всех ресурсов.
   • variables.tf: содержит объявления переменных, используемых в main.tf. Чтобы улучшить читаемость кода, размещайте обязательные переменные вверху, а необязательные — внизу, разделяя их строкой комментария;
   • outputs.tf: содержит выходные данные ресурсов, созданных в main.tf;
   • versions.tf: содержит требования к версиям Terraform и поставщиков;
   • data.tf: содержит импорт ресурсов;
   • resource.tf: содержит объявление конкретного ресурса;
   • terraform.tfvars: содержит значения переменных. Нигде не должен использоваться.

2. Упорядочьте ключи в блоке переменных variables.tf следующим образом: description, type, default, validation.

3. Используйте динамические блоки. Они позволяют создавать конфигурации с более высокой степенью гибкости и автоматизации. Их используют для генерирования повторяющихся блоков кода на основе входных данных, что упрощает управление инфраструктурой и уменьшает объём дублирующегося кода.

4. Старайтесь делать ваши модули ресурсов максимально простыми.

5. Указывайте версии ваших модулей, иначе вы можете столкнуться с неожиданными проблемами при очередном развертывании. Для обновления ваших модулей используйте семантическое версионирование.

6. Если ваши модули тесно связаны — объедините их в один. Такие модули можно хранить в одном репозитории и использовать их в качестве подмодулей. Так вы сможете версионировать их как единое целое, и управлять ими станет проще.

7. Используйте map вместо list для описания группы объектов. Если требуется создать группу идентичных объектов, то лучше использовать map, так ресурсы будут обновляться. При использовании list ресурсы пересоздаются. Для некоторых сценариев это критично.

#bestpractices #devops #terraform