Рассказываю про ещё один замечательный продукт Jetbrains, с которым знаком лично - Teamcity. Как и Youtrack, он имеет бесплатную версию с ограничениями, которые позволят небольшой команде полноценно пользоваться бесплатной версией. Серверную часть можно будет настроить на своём железе.
TeamCity это прямой аналог Jenkins и Gitlab. Я впервые с ним познакомился много лет назад, когда ещё ни навыков, ни теории по CI/CD у меня не было. Знакомые разработчики, с которыми сотрудничал, поставили у себя и попросили им помочь настроить деплой некоторых проектов, работающих в Docker.
На удивление, мне не составило большого труда в течении одного дня разобраться и сделать несколько простых пайплайнов. Потом уже их дорабатывали по мере развития проектов.
TeamCity очень дружественен к пользователям. У него меньше функционала по сравнению с Gitlab, но и разобраться с ним в разы проще. Даже если у вас сейчас настроены какие-то костыли на скриптах, то попробуйте для начала их перенести в TeamCity как есть. Там можно прям в шагах ходить по ssh на сервера и что-то делать. Потом уже вникая в нюансы и возможности, потихоньку будете переделывать на нормальный вариант.
▶️ Свежее видео на английском по установке Teamcity, подключению к репозиторию, созданию сборки, подключению агента и запуска сборки:
⇨ https://www.youtube.com/watch?v=zqi4fDF-S60
Если хотите въехать побыстрее в тему CI/CD, то самостоятельно начать с Teamcity нормальный ход. Я позже проходил обучение по Gitlab. Субъективно могу сказать, что с него стартануть сложнее. Он более замороченный, но, конечно, изучать его тоже необходимо.
⇨ Сайт
#cicd #devops
TeamCity это прямой аналог Jenkins и Gitlab. Я впервые с ним познакомился много лет назад, когда ещё ни навыков, ни теории по CI/CD у меня не было. Знакомые разработчики, с которыми сотрудничал, поставили у себя и попросили им помочь настроить деплой некоторых проектов, работающих в Docker.
На удивление, мне не составило большого труда в течении одного дня разобраться и сделать несколько простых пайплайнов. Потом уже их дорабатывали по мере развития проектов.
TeamCity очень дружественен к пользователям. У него меньше функционала по сравнению с Gitlab, но и разобраться с ним в разы проще. Даже если у вас сейчас настроены какие-то костыли на скриптах, то попробуйте для начала их перенести в TeamCity как есть. Там можно прям в шагах ходить по ssh на сервера и что-то делать. Потом уже вникая в нюансы и возможности, потихоньку будете переделывать на нормальный вариант.
▶️ Свежее видео на английском по установке Teamcity, подключению к репозиторию, созданию сборки, подключению агента и запуска сборки:
⇨ https://www.youtube.com/watch?v=zqi4fDF-S60
Если хотите въехать побыстрее в тему CI/CD, то самостоятельно начать с Teamcity нормальный ход. Я позже проходил обучение по Gitlab. Субъективно могу сказать, что с него стартануть сложнее. Он более замороченный, но, конечно, изучать его тоже необходимо.
⇨ Сайт
#cicd #devops
▶️ Если для вас интересна тема CI/CD, вы уже специалист с некоторым опытом или только начинаете изучать devops, могу порекомендовать отличное по качеству обзорное видео с фундаментальным материалом:
Идеальный CI/CD pipeline. What is Continuous Integration / Continuous Delivery?
⇨ https://www.youtube.com/watch?v=wXJgB9oZsBo
Очень приятный формат подачи: атмосфера, качественная картинка, звук, презентации, временные метки. Участники внятно и содержательно общаются, хорошая дикция и ведение диалога.
Это первое видео от данного канала, которое я увидел. Даже удивился, что у них так мало просмотров и подписчиков. Мне кажется, с таким качеством материала, у них всего должно быть побольше.
Только есть одна проблема. Где найти свободное время, чтобы слушать такие длинные подкасты?
#видео #devops #cicd
Идеальный CI/CD pipeline. What is Continuous Integration / Continuous Delivery?
⇨ https://www.youtube.com/watch?v=wXJgB9oZsBo
Очень приятный формат подачи: атмосфера, качественная картинка, звук, презентации, временные метки. Участники внятно и содержательно общаются, хорошая дикция и ведение диалога.
Это первое видео от данного канала, которое я увидел. Даже удивился, что у них так мало просмотров и подписчиков. Мне кажется, с таким качеством материала, у них всего должно быть побольше.
Только есть одна проблема. Где найти свободное время, чтобы слушать такие длинные подкасты?
#видео #devops #cicd
▶️ Понравилось ещё одно выступление с DevOpsConf, которое могу порекомендовать к просмотру:
⇨ DevOps спит, Gitlab CI работает
Выступление будет интересно тем, кто хочет на примерах посмотреть, что такое CI/CD на практике. Не абстрактные интеграции и доставки, а по шагам, что конкретно делаем.
Автор доклада рассказала, как они жили до CI/CD и вручную выполняли все операции по заявкам разработчиков. И как в итоге всё автоматизировали с помощью Gitlab, чтобы вручную не делать ничего. Каждый шаг своего конвейера она описывает. Собственно, об этом весь доклад.
Обратил внимание, что крупная компания использует Rocket.Chat для внутреннего общения. Мне предстоит уже на днях внедрение в небольшую компанию на 50 человек. Расскажу потом, как всё прошло. Самому интересно в работе посмотреть на этот продукт. Дальше тестов никогда дело не заходило. Был опыт внедрения и использования Mattermost и Zulip.
Отдельно хочется отметить, что Виктория начала свой путь с первой линии поддержки в 2018 году. А уже в 2020 стала DevOps инженером. В 2022 выступает на конференции для специалистов. Хорошая мотивирующая история. Дорогу осилит идущий.
#видео #devops #cicd
⇨ DevOps спит, Gitlab CI работает
Выступление будет интересно тем, кто хочет на примерах посмотреть, что такое CI/CD на практике. Не абстрактные интеграции и доставки, а по шагам, что конкретно делаем.
Автор доклада рассказала, как они жили до CI/CD и вручную выполняли все операции по заявкам разработчиков. И как в итоге всё автоматизировали с помощью Gitlab, чтобы вручную не делать ничего. Каждый шаг своего конвейера она описывает. Собственно, об этом весь доклад.
Обратил внимание, что крупная компания использует Rocket.Chat для внутреннего общения. Мне предстоит уже на днях внедрение в небольшую компанию на 50 человек. Расскажу потом, как всё прошло. Самому интересно в работе посмотреть на этот продукт. Дальше тестов никогда дело не заходило. Был опыт внедрения и использования Mattermost и Zulip.
Отдельно хочется отметить, что Виктория начала свой путь с первой линии поддержки в 2018 году. А уже в 2020 стала DevOps инженером. В 2022 выступает на конференции для специалистов. Хорошая мотивирующая история. Дорогу осилит идущий.
#видео #devops #cicd
Предлагаю вашему вниманию любопытную утилиту, которую мне давно посоветовали посмотреть в контексте обсуждения темы Port knocking. На практике она может пригодиться в очень широком диапазоне костылей.
Речь пойдёт про программу updater. Она слушает запросы на специальный url и выполняет заданные действия, если запрос легитимный. То есть курлом можно дёрнуть какой-то урл и на сервере выполнится определённое действие. Например, iptables создаст разрешающее правила для подключения по ssh. Урлы можно выбирать любые, в том числе те, что не поддаются подбору. А также наличие аутентификации через токен, делают этот инструмент замаскированным и относительно безопасным. Можно посадить его за прокси, чтобы совсем спрятать.
У автора в репозитории примеры сразу в составе с docker-compose с использованием reproxy в качестве reversed proxy. Если хотите просто погонять утилиту и посмотреть, как работает, может приспособить для своих простых задач, то можете просто запустить в одиночном контейнере:
Создаёте директорию etc там, откуда будете запускать команду. В неё положите конфиг
Формат yaml, так что будьте аккуратны с пробелами. Теперь проверяем, как работает:
Думаю, принцип понятен. Автор пишет, что написал этот софт для использования в CI/CD без необходимости работы по SSH, а следовательно передачи паролей или ключей. По его задумке с помощью updater можно выполнять обновление и перезапуск docker контейнеров. Для этого в составе его контейнера есть docker client и туда пробрасывается docker.sock.
Кстати, его идею я сразу понял, так как в простых случаях я именно так и костылил в Teamcity. Заходил по SSH, обновлял и перезапускал контейнер консольными командами. В целом, это не очень хорошая практика, но задачу решает быстро и в лоб. Для небольших проектов нормальная тема. До этого разработчики руками это делали. Потом попросили настроить что-нибудь для автоматизации. Я воткнул бесплатный Teamcity и автоматизировал в лоб все их действия. Они были довольны.
Для работы на хосте updater нужно вытащить из контейнера и запустить напрямую. Это не трудно сделать, так как updater обычное приложение на GO, состоящее из одного бинарника. Ключи описаны автором в репозитории.
Теперь можно запускать локально. Полезная небольшая утилита. Рекомендую запомнить её. Напомню, что есть похожая программа, про которую я пару раз писал и использую сам - labean.
⇨ Исходники
#security #cicd #devops
Речь пойдёт про программу updater. Она слушает запросы на специальный url и выполняет заданные действия, если запрос легитимный. То есть курлом можно дёрнуть какой-то урл и на сервере выполнится определённое действие. Например, iptables создаст разрешающее правила для подключения по ssh. Урлы можно выбирать любые, в том числе те, что не поддаются подбору. А также наличие аутентификации через токен, делают этот инструмент замаскированным и относительно безопасным. Можно посадить его за прокси, чтобы совсем спрятать.
У автора в репозитории примеры сразу в составе с docker-compose с использованием reproxy в качестве reversed proxy. Если хотите просто погонять утилиту и посмотреть, как работает, может приспособить для своих простых задач, то можете просто запустить в одиночном контейнере:
# docker run -p 8080:8080 -e LISTEN=0.0.0.0:8080 \-e KEY=super-secret-password \-e CONF=/srv/etc/updater.yml \--name=updater -v ./etc:/srv/etc \ghcr.io/umputun/updater:masterСоздаёте директорию etc там, откуда будете запускать команду. В неё положите конфиг
updater.yml для простейшего задания с echo:tasks: - name: echo-test command: | echo "Test updater work"Формат yaml, так что будьте аккуратны с пробелами. Теперь проверяем, как работает:
# curl 172.17.196.25:8080/update/echo-test/super-secret-password{"task":"echo-test","updated":"ok"}Думаю, принцип понятен. Автор пишет, что написал этот софт для использования в CI/CD без необходимости работы по SSH, а следовательно передачи паролей или ключей. По его задумке с помощью updater можно выполнять обновление и перезапуск docker контейнеров. Для этого в составе его контейнера есть docker client и туда пробрасывается docker.sock.
Кстати, его идею я сразу понял, так как в простых случаях я именно так и костылил в Teamcity. Заходил по SSH, обновлял и перезапускал контейнер консольными командами. В целом, это не очень хорошая практика, но задачу решает быстро и в лоб. Для небольших проектов нормальная тема. До этого разработчики руками это делали. Потом попросили настроить что-нибудь для автоматизации. Я воткнул бесплатный Teamcity и автоматизировал в лоб все их действия. Они были довольны.
Для работы на хосте updater нужно вытащить из контейнера и запустить напрямую. Это не трудно сделать, так как updater обычное приложение на GO, состоящее из одного бинарника. Ключи описаны автором в репозитории.
# docker cp f41a990d84c0:/srv/updater updaterТеперь можно запускать локально. Полезная небольшая утилита. Рекомендую запомнить её. Напомню, что есть похожая программа, про которую я пару раз писал и использую сам - labean.
⇨ Исходники
#security #cicd #devops
Я уже не раз делал заметки про Gitea - легковесную open source систему для управления git репозиториями. Изначально это был просто веб интерфейс для git, который можно было сделать с помощью соответствующей темы очень похожей на github. Написана Gitea на Go и по своей сути это просто бинарник, поэтому с установкой и настройкой никаких проблем. Бонусом гошечки идёт очень быстрая работа и отзывчивость веб интерфейса.
Как я уже сказал, Gitea была создана просто для работы с кодом, без какой-либо автоматизации. Для построения конвейера для сборки, деплоя и хранения образов я предлагал связку: Gitea + Drone CI + Docker Registry.
С недавних пор в Gitea завезли Gitea Actions, которые полностью совместимы с GitHub Actions. То есть она превратилась в полноценную CI/CD систему с собственным Package Registry и Gitea Runner. Получился аналог gitlab на минималках.
Подробно посмотреть обзор всех этих возможностей, а также инструкцию по настройке, можно в серии из двух видеороликов:
▶️ Gitea-01: домашний github (+ actions)
▶️ Gitea-02: домашний github (+ actions)
#git #devops #cicd
Как я уже сказал, Gitea была создана просто для работы с кодом, без какой-либо автоматизации. Для построения конвейера для сборки, деплоя и хранения образов я предлагал связку: Gitea + Drone CI + Docker Registry.
С недавних пор в Gitea завезли Gitea Actions, которые полностью совместимы с GitHub Actions. То есть она превратилась в полноценную CI/CD систему с собственным Package Registry и Gitea Runner. Получился аналог gitlab на минималках.
Подробно посмотреть обзор всех этих возможностей, а также инструкцию по настройке, можно в серии из двух видеороликов:
▶️ Gitea-01: домашний github (+ actions)
▶️ Gitea-02: домашний github (+ actions)
#git #devops #cicd
YouTube
Gitea-01: домашний github (+ actions)
Рассмотрим: gitea - альтернативу gitlab, в которую завезли actions от github.
Ближайшие и доступные курсы можно посмотреть в школе - https://realmanual.ru
Ближайшие и доступные курсы можно посмотреть в школе - https://realmanual.ru
Для автоматической проверки Docker образов на уязвимости (CVE) есть хороший open source инструмент Trivy. Год назад я делал по нему пару заметок с обзором и автоматическим исправлением уязвимостей. Потом всё это в небольшую статью оформил.
Этот продукт хорошо дополняет open source утилита Dockle. Она тоже проверяет контейнеры на уязвимости, но помимо этого проверяет образ на соответствие best-practice Dockerfile и рекомендации CIS Docker Benchmarks (#cis).
Использовать очень просто, так как это по сути одиночный бинарник. В репозитории есть пакеты для установки под все популярные системы. Можно запустить и в Docker без установки:
Пример отчёта можно посмотреть на тестовом образе, для которого есть замечания:
С помощью ключа
⇨ Исходники
#docker #devops #cicd #security
Этот продукт хорошо дополняет open source утилита Dockle. Она тоже проверяет контейнеры на уязвимости, но помимо этого проверяет образ на соответствие best-practice Dockerfile и рекомендации CIS Docker Benchmarks (#cis).
Использовать очень просто, так как это по сути одиночный бинарник. В репозитории есть пакеты для установки под все популярные системы. Можно запустить и в Docker без установки:
# docker run --rm goodwithtech/dockle:v0.4.14 [YOUR_IMAGE_NAME]Пример отчёта можно посмотреть на тестовом образе, для которого есть замечания:
# docker run --rm goodwithtech/dockle:v0.4.14 goodwithtech/dockle-test:v2С помощью ключа
-f json вывод можно сохранить в json файле. Dockle легко интегрировать в пайплайн. В репозитории есть примеры (gitlab).⇨ Исходники
#docker #devops #cicd #security
Я в пятницу рассказал про систему мониторинга Gatus. Система мне понравилась, так что решил её сразу внедрить у себя. Понравилась за 3 вещи:
▪️ простая настройка в едином конфигурационном файле;
▪️ информативные уведомления в Telegram;
▪️ наглядный дашборд со статусами как отдельных проверок, так и объединённых в группы.
На примере настройки Gatus я покажу, как собрал простейший конвейер по деплою настроек для этой системы мониторинга.
Настройка Gatus у меня сейчас выглядит следующим образом. Я открываю в VSCode конфигурационный файл config.yaml, который сохранён у меня локально на ноуте. Вношу в него правки, сохраняю и пушу в git репозиторий. Дальше изменения автоматом доходят до VPS, где всё развёрнуто и автоматически применяются. Через 10 секунд после пуша я иду в браузере проверять изменения.
Рассказываю по шагам, что я сделал для этого.
1️⃣ Взял самую простую VPS с 1 CPU и 1 GB оперативной памяти. Установил туда Docker и запустил Gatus.
2️⃣ В бесплатной учётной записи на gitlab.com создал отдельный репозиторий для Gatus.
3️⃣ На VPS установил gitlub-runner с shell executor, запустил и подключил к проекту Gatus.
4️⃣ Для проекта настроил простейший CI/CD средствами Gitlab (по факту только CD) с помощью файла
5️⃣ Скопировал репозиторий к себе на ноут, где установлен VSCode с расширением GitLab Workflow. С его помощью подключаю локальные репозитории к репозиториям gitlab.
Итого у меня в репозитории 2 файла:
◽
◽
Когда мне нужно добавить или отредактировать проверку в Gatus, я открываю у себя на ноуте конфиг и вношу туда изменения. Коммичу их и пушу изменения в репозиторий в Gitlab. Сервис видит наличие файла
На простом примере показал, как работает простейшая доставка кода на целевую машину и его применение. Даже если вы не участвуете в разработке ПО, рекомендую разобраться с этой темой и применять на практике. Это много где может пригодится даже чисто в админских делах.
#devops #cicd
▪️ простая настройка в едином конфигурационном файле;
▪️ информативные уведомления в Telegram;
▪️ наглядный дашборд со статусами как отдельных проверок, так и объединённых в группы.
На примере настройки Gatus я покажу, как собрал простейший конвейер по деплою настроек для этой системы мониторинга.
Настройка Gatus у меня сейчас выглядит следующим образом. Я открываю в VSCode конфигурационный файл config.yaml, который сохранён у меня локально на ноуте. Вношу в него правки, сохраняю и пушу в git репозиторий. Дальше изменения автоматом доходят до VPS, где всё развёрнуто и автоматически применяются. Через 10 секунд после пуша я иду в браузере проверять изменения.
Рассказываю по шагам, что я сделал для этого.
1️⃣ Взял самую простую VPS с 1 CPU и 1 GB оперативной памяти. Установил туда Docker и запустил Gatus.
2️⃣ В бесплатной учётной записи на gitlab.com создал отдельный репозиторий для Gatus.
3️⃣ На VPS установил gitlub-runner с shell executor, запустил и подключил к проекту Gatus.
4️⃣ Для проекта настроил простейший CI/CD средствами Gitlab (по факту только CD) с помощью файла
.gitlab-ci.yml. Добавил туда всего 3 действия:deploy-prod: stage: deploy script: - cd /home/gitlab-runner/gatus - git pull - /usr/bin/docker restart gatus5️⃣ Скопировал репозиторий к себе на ноут, где установлен VSCode с расширением GitLab Workflow. С его помощью подключаю локальные репозитории к репозиториям gitlab.
Итого у меня в репозитории 2 файла:
◽
config.yaml - конфигурация gatus◽
.gitlab-ci.yml - описание команд, которые будет выполнять gitlab-runnerКогда мне нужно добавить или отредактировать проверку в Gatus, я открываю у себя на ноуте конфиг и вношу туда изменения. Коммичу их и пушу изменения в репозиторий в Gitlab. Сервис видит наличие файла
.gitlab-ci.yml и отдаёт команду gitlab-runner, установленному на VPS на выполнение заданных действий: обновление локального репозитория, чтобы поучить обновлённый конфиг и перезапуск контейнера, который необходим для применения изменений. На простом примере показал, как работает простейшая доставка кода на целевую машину и его применение. Даже если вы не участвуете в разработке ПО, рекомендую разобраться с этой темой и применять на практике. Это много где может пригодится даже чисто в админских делах.
#devops #cicd
На прошлой неделе посмотрел видео про современную и функциональную open source платформу для управления веб приложениями, запускаемыми в Docker контейнерах. Речь пойдёт про Coolify. Вот видео, о котором я говорю:
▶️ Coolify - deploy services locally, or on remote servers!
Не стал его включать в регулярную подборку, потому что решил развернуть и попробовать систему, а потом отдельно про неё написать. Сейчас это сделаю.
Для того, чтобы сразу было понятно, что такое Coolify, скажу, что это условный аналог известного сервиса Heroku. Конечно, не такой функциональный, но он и появился не так давно. При этом на github у него огромное количество звёзд (34k), много спонсоров, большое сообщество и регулярные обновления. Проект монетизируется за счёт облачной версии.
Поясню своими словами, как работает Coolify. Условно её можно сравнить с панелью управления хостингом или VPS, только тут конечные сущности - приложения, запускаемые в контейнерах.
Вы разворачиваете панель и добавляете в неё следующие объекты:
▪️чистые сервера на базе Linux, которыми coolify управляет по ssh;
▪️s3 хранилища;
▪️git репозитории с вашим кодом;
▪️проекты, которые могут состоять из разных окружений (dev, prod и т.д.)
▪️переменные, ключи и токены;
▪️команды и пользователей
После этого вы идёте в один из проектов и создаёте там новый ресурс в виде вашего приложения, запущенного из готового образа, из Dockerfile или Docker-compose. Связываете это приложение, если необходимо, с соответствующим репозиторием кода, публикуете его на одном из добавленных серверов. Настраиваете к нему доступ по отдельному доменному имени. Для этого Coolify поднимает свой обратный прокси на базе Caddy или Traefik, получает сертификаты от Let's Encrypt.
Вы всем этим управляете из общего веб интерфейса с дашбордами. Все проекты и приложения, соответственно, бьются на команды с разными правами доступа. Помимо ваших приложений, подобным образом можно разворачивать популярные СУБД или преднастроенные сервисы на базе образов от linuxserver.io.
Проект довольно навороченный. Там много всего добавлено. Есть API, аутентификация через различных OAuth провайдеров, публикация ваших приложений через какой-то dyndns сервис, вебхуки, оповещения. Есть возможность подключаться к консоли серверов и контейнеров. Можно не ходить напрямую по ssh, а всем управлять через веб панель.
Даже не знаю, с чем Coolify сравнить. Не припоминаю похожих проектов. Он интересен и для личной инфраструктуры, если у вас большой набор своих сервисов, и для каких-то команд, особенно разработчиков. Можно всё для них автоматизировать и дать доступ. Они и консоли, и логи, и бэкапы своих приложений увидят. Смогут всем этим управлять, к примеру, в dev окружении и только смотреть в prod.
❗️Отдельно подчеркну ещё раз. Всё это только для Docker контейнеров. Деплоить что-то в обычное окружение Linux нельзя. Coolify автоматом на все добавляемые сервера устанавливает Docker.
⇨ 🌐 Сайт (через VPN) / 4️⃣ Исходники / Скриншоты интерфейса
#docker #devops #cicd
▶️ Coolify - deploy services locally, or on remote servers!
Не стал его включать в регулярную подборку, потому что решил развернуть и попробовать систему, а потом отдельно про неё написать. Сейчас это сделаю.
Для того, чтобы сразу было понятно, что такое Coolify, скажу, что это условный аналог известного сервиса Heroku. Конечно, не такой функциональный, но он и появился не так давно. При этом на github у него огромное количество звёзд (34k), много спонсоров, большое сообщество и регулярные обновления. Проект монетизируется за счёт облачной версии.
Поясню своими словами, как работает Coolify. Условно её можно сравнить с панелью управления хостингом или VPS, только тут конечные сущности - приложения, запускаемые в контейнерах.
Вы разворачиваете панель и добавляете в неё следующие объекты:
▪️чистые сервера на базе Linux, которыми coolify управляет по ssh;
▪️s3 хранилища;
▪️git репозитории с вашим кодом;
▪️проекты, которые могут состоять из разных окружений (dev, prod и т.д.)
▪️переменные, ключи и токены;
▪️команды и пользователей
После этого вы идёте в один из проектов и создаёте там новый ресурс в виде вашего приложения, запущенного из готового образа, из Dockerfile или Docker-compose. Связываете это приложение, если необходимо, с соответствующим репозиторием кода, публикуете его на одном из добавленных серверов. Настраиваете к нему доступ по отдельному доменному имени. Для этого Coolify поднимает свой обратный прокси на базе Caddy или Traefik, получает сертификаты от Let's Encrypt.
Вы всем этим управляете из общего веб интерфейса с дашбордами. Все проекты и приложения, соответственно, бьются на команды с разными правами доступа. Помимо ваших приложений, подобным образом можно разворачивать популярные СУБД или преднастроенные сервисы на базе образов от linuxserver.io.
Проект довольно навороченный. Там много всего добавлено. Есть API, аутентификация через различных OAuth провайдеров, публикация ваших приложений через какой-то dyndns сервис, вебхуки, оповещения. Есть возможность подключаться к консоли серверов и контейнеров. Можно не ходить напрямую по ssh, а всем управлять через веб панель.
Даже не знаю, с чем Coolify сравнить. Не припоминаю похожих проектов. Он интересен и для личной инфраструктуры, если у вас большой набор своих сервисов, и для каких-то команд, особенно разработчиков. Можно всё для них автоматизировать и дать доступ. Они и консоли, и логи, и бэкапы своих приложений увидят. Смогут всем этим управлять, к примеру, в dev окружении и только смотреть в prod.
❗️Отдельно подчеркну ещё раз. Всё это только для Docker контейнеров. Деплоить что-то в обычное окружение Linux нельзя. Coolify автоматом на все добавляемые сервера устанавливает Docker.
⇨ 🌐 Сайт (через VPN) / 4️⃣ Исходники / Скриншоты интерфейса
#docker #devops #cicd