Telegram Group & Telegram Channel
Универсальный стек для работы без Docker Compose

Удивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был Docker Compose и они не видели других способов работы. Когда-то я рассказывал как перейти на Docker Compose, а теперь пришла пора говорить о том, как работать без него :)

Docker Compose, в первую очередь, нужен для унификации среды разработки, чтобы сетап был единым независимо от того, где вы его разворачиваете и что там на машине было установлено. Как ни странно, все это было и до него, например через Vagrant (Кто еще застал разработку через него?). Переход на Compose произошел из-за повального движения в сторону легковестных контейнеров, а не полноценных виртуальных машин. К тому же Docker становился стандартом в продакшене, что давало возможность переиспользовать Dockerfile для разработки и продакшена. Но реальная жизнь оказалась сложнее. По порядку:

1. Единый Dockerfile для продакшена и девелопмента это миф и работает только в примитивных случаях
2. Постоянные сложности с настройкой сервисов, так как работа внутри контейнера часто требует особой конфигурации, запуска в хедлес режимах и указания специальных переменных окружений.
3. Compose значительно усложняет процесс разработки: внутри/снаружи, установка зависимостей, персистентность (игра с волюмами).
4. Compose требует шаманств в работе с редактором. Чтобы заставить работать lsp сервера и линтеры, нужно научить их ходить во внутрь контейнера, либо как-то имитировать идентичный сетап снаружи.

В итоге решая буквально одноразовую задачу по первоначальному сетапу, Compose значительно ухудшает сам процесс разработки, с которым мы сталкиваемся каждый день. Можно ли отказаться от него, не потеряв те преимущества, которые он дал? На 100% нельзя, но можно сделать достаточно хороший сетап, который уберет большую часть проблем и точно будет намного приятнее в использовании. Что для этого надо?

1. Автоматизация команд с зависимостями. Тут берем Make или его аналог https://www.youtube.com/watch?v=pK9mF5aK05Q
2. Mise - универсальная тулза для установки языков: https://mise.jdx.dev/
3. Overmind: Менеджер процессов, позволяет запускать наборы сервисов как DC: https://github.com/DarthSim/overmind (раньше для этого использовали Foreman, формат кстати остался тот же)
4. Как ни странно тот же Docker. Например не имеет смысл ставить базу прямо в систему, ее можно запускать так же в контейнере, но без Compose

Все это можно подсмотреть в нашем продакшен проекте https://github.com/hexlet-basics/hexlet-basics/blob/main/Makefile

Что еще? Пожалуй главная засада это первоначальная настройка вашей операционки. В маке что-то надо поставить через brew, в ubuntu через apt. Но опять же, решается все это крайне просто через тот же Make:


macos-setup:
brew install overmind caddy


Но даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.

Ссылки: Телеграм | Youtube | VK



group-telegram.com/orgprog/317
Create:
Last Update:

Универсальный стек для работы без Docker Compose

Удивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был Docker Compose и они не видели других способов работы. Когда-то я рассказывал как перейти на Docker Compose, а теперь пришла пора говорить о том, как работать без него :)

Docker Compose, в первую очередь, нужен для унификации среды разработки, чтобы сетап был единым независимо от того, где вы его разворачиваете и что там на машине было установлено. Как ни странно, все это было и до него, например через Vagrant (Кто еще застал разработку через него?). Переход на Compose произошел из-за повального движения в сторону легковестных контейнеров, а не полноценных виртуальных машин. К тому же Docker становился стандартом в продакшене, что давало возможность переиспользовать Dockerfile для разработки и продакшена. Но реальная жизнь оказалась сложнее. По порядку:

1. Единый Dockerfile для продакшена и девелопмента это миф и работает только в примитивных случаях
2. Постоянные сложности с настройкой сервисов, так как работа внутри контейнера часто требует особой конфигурации, запуска в хедлес режимах и указания специальных переменных окружений.
3. Compose значительно усложняет процесс разработки: внутри/снаружи, установка зависимостей, персистентность (игра с волюмами).
4. Compose требует шаманств в работе с редактором. Чтобы заставить работать lsp сервера и линтеры, нужно научить их ходить во внутрь контейнера, либо как-то имитировать идентичный сетап снаружи.

В итоге решая буквально одноразовую задачу по первоначальному сетапу, Compose значительно ухудшает сам процесс разработки, с которым мы сталкиваемся каждый день. Можно ли отказаться от него, не потеряв те преимущества, которые он дал? На 100% нельзя, но можно сделать достаточно хороший сетап, который уберет большую часть проблем и точно будет намного приятнее в использовании. Что для этого надо?

1. Автоматизация команд с зависимостями. Тут берем Make или его аналог https://www.youtube.com/watch?v=pK9mF5aK05Q
2. Mise - универсальная тулза для установки языков: https://mise.jdx.dev/
3. Overmind: Менеджер процессов, позволяет запускать наборы сервисов как DC: https://github.com/DarthSim/overmind (раньше для этого использовали Foreman, формат кстати остался тот же)
4. Как ни странно тот же Docker. Например не имеет смысл ставить базу прямо в систему, ее можно запускать так же в контейнере, но без Compose

Все это можно подсмотреть в нашем продакшен проекте https://github.com/hexlet-basics/hexlet-basics/blob/main/Makefile

Что еще? Пожалуй главная засада это первоначальная настройка вашей операционки. В маке что-то надо поставить через brew, в ubuntu через apt. Но опять же, решается все это крайне просто через тот же Make:


macos-setup:
brew install overmind caddy


Но даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.

Ссылки: Телеграм | Youtube | VK

BY Организованное программирование | Кирилл Мокевнин


Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260

Share with your friend now:
group-telegram.com/orgprog/317

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

"And that set off kind of a battle royale for control of the platform that Durov eventually lost," said Nathalie Maréchal of the Washington advocacy group Ranking Digital Rights. Stocks dropped on Friday afternoon, as gains made earlier in the day on hopes for diplomatic progress between Russia and Ukraine turned to losses. Technology stocks were hit particularly hard by higher bond yields. Channels are not fully encrypted, end-to-end. All communications on a Telegram channel can be seen by anyone on the channel and are also visible to Telegram. Telegram may be asked by a government to hand over the communications from a channel. Telegram has a history of standing up to Russian government requests for data, but how comfortable you are relying on that history to predict future behavior is up to you. Because Telegram has this data, it may also be stolen by hackers or leaked by an internal employee. READ MORE DFR Lab sent the image through Microsoft Azure's Face Verification program and found that it was "highly unlikely" that the person in the second photo was the same as the first woman. The fact-checker Logically AI also found the claim to be false. The woman, Olena Kurilo, was also captured in a video after the airstrike and shown to have the injuries.
from ye


Telegram Организованное программирование | Кирилл Мокевнин
FROM American