Так как апгрейд будет неминуем - лучше, кажется, раньше чем позже. Как раз потом воросов (переделок) будет поменьше. Да и прям мажорных-мажорных изменений не увидел, ежели честно. А ваш покорныйслуга как раз сторонник distro-less подхода, т.е. поставлять только то, что надо. Как вариант, держать альтернативный тег с постфиксом alpine, для дебага (так, к слову, podman делает, да и не только он), как вариант :)
Да, но так правильнее что-ли... Если есть возможность ограничить ресурсы одним скоупом - то лучше так делать. Хотя, для локальной разработки, может и нахрен
запускать traefik в контейнере с --network host
Для локального контейнера с открытыми сорцами - думаю, это вполне себе ок
Так что флаг --rm я бы убрал
Этот флаг немного не про то. Он про Automatically remove the container when it exits и не более
Мне вот всегда было интересно, чем же руководствуются те, что генерируют спецификацию из кода? Ведь спецификация есть нечто иное, как контракт для взаимодействия между системами, т.е. она должна являться источником истины, а не наоборот.
В реальном мире это можно представить как взаимоотношение, например, клиента и банка. Условия, на которых банк оказываем услуги (не обнуляет ваши счета, начисляет проценты по вкладам и так далее) зависели бы от того, как банк фактически обходится с вашими средствами, а не от того, на каких условиях вы заключили с ним контракт (договор, условия обслуживая и т.п.).
Борис, вы безусловно большой молодец, что разобрались со своим кейсом и поделились опытом! Но мне вот просто интересно - почему бы не описать спецификацию в yaml/json формате, и из неё уже сгенерировать код под Echo сервер используя, например, deepmap/oapi-codegen? Вносить изменения будет так же просто - изменили спеку (контракт), сгенерировали соответствующий код, поправили имплементацию. Но правило источника истины в этом случае сохраняется, и бережёт вас же от обратно-несовместимых изменений, и значительно упрощает ревью. Да и кода будет меньше, и поддерживать 3rd party решение вам не придётся.
Домен-то такой мы завести можем, а вот certbot начинает ругаться:
An unexpected error occurred:
Error creating new order :: Cannot issue for "*.__docker__.indocker.app": Domain name contains an invalid character
Так что пользуемся *.x-docker.indocker.app:
$ dig +noall +answer -t A bar.x-docker.indocker.app
bar.x-docker.indocker.app. 300 IN A 172.17.0.1
$ dig +noall +answer -t A foo.bar.x-docker.indocker.app
foo.bar.x-docker.indocker.app. 300 IN A 172.17.0.1
Релизнуто в v1.1.1. Играйтесь на здоровье, как будет чем поделиться - сюда или в личку черканите, пожалуйста :3
Интересное предложение. Давайте так - я могу для вас (теста для) зону завести, скажем, вида *.__habr_sabmaks__.indocker.app, которая будет резольвится в 172.17.0.1. Вы сможете вдоволь наиграться, а после этого поделиться обратной связью. Если подводных комней не встретите (или элегантно их обойдёте) - то конечно впилим это как перманентную фичу
Речь только о локальном окружении, повторюсь. Вот есть у вас, к примеру, сервис (и не редко не один), что состоит из фронтенда и нескольких бэкэндов, и все они разрабатываются с использованием докера. Чтоб с ними взаимодействовать локально вам, скорее всего надо будет пробросить их порты в хост (обращаясь к ним 127.0 0.1:8080, 127.0.0.1:8081 и так далее). И вот вопрос - что для вас удобнее - держать в голове что и на каком порту крутится, или использовать "человеческие" доменные имена вида api.indocker.app, web.indocker.app и тому подобные? Да чтоб еще и tls сертификат был из коробки для них, валидный всюду? Вот статья как раз про это :) Ничего никуда не привязывается, так как работает исключительно на вашей машине, и работает везде, где есть возможность запустить демон докера; под окнами, линуксом и маком, под amd и arm. Так стало понятнее? Извиняюсь, что не удалось это сразу отразить в статье. Видимо, "глаз уже замылился" несколько
В теории, наверное, можно, но не делал так никогда. Если у вас есть опыт и сценарий автоматизации этого - поделитесь?
В hosts прописывать желание пропало после второго раза. Ровно как и держать локальный резольвер типа dnsmasq на зону. Ты же не один работаешь, а всех в командах учить этому, да на зоопарке систем - совсем печаль-тоска. Да, забыл уточнить в статье - ttl у dns записей, что указывают на локалхост - одни сутки. Так что если моргнет сеть на пару часов, и ttl не игнорится локальным кэшем - проблем не должно быть.
Для совсем локальных историй есть mkcert (ссылка на него есть в статье), но это опять-таки телодвижения :)
Для однотипных проектов давно придуман boilerplate, но придумать проблему и мужественно ее решить - тоже отдельный вид искусства, согласен (извиняюсь за токсичность)
Полностью поддерживаю комментатора выше, 3proxy отличный выбор из категории "запустил и забыл" (написан на C).
Для его запуска в докере, пару лет назад создал образ с entrypoint скриптом, который заведует конфигом авторизации - никакой дополнительный конфиг даже пробрасывать внутрь контейнера не надо.
Так как апгрейд будет неминуем - лучше, кажется, раньше чем позже. Как раз потом воросов (переделок) будет поменьше. Да и прям мажорных-мажорных изменений не увидел, ежели честно.
А ваш покорныйслуга как раз сторонник distro-less подхода, т.е. поставлять только то, что надо. Как вариант, держать альтернативный тег с постфиксом alpine, для дебага (так, к слову, podman делает, да и не только он), как вариант :)
Ох, круто! А могли бы вы создать PR с изменениями? Может ещё чего "по дороге" заметите :)
Да, но так правильнее что-ли... Если есть возможность ограничить ресурсы одним скоупом - то лучше так делать. Хотя, для локальной разработки, может и нахрен
Для локального контейнера с открытыми сорцами - думаю, это вполне себе ок
Этот флаг немного не про то. Он про
Automatically remove the container when it exitsи не болееНо только не
always, аunless-stoppedтогда уж :DБлин, а это же самое интересное!
А это не зона ли ответственности E2E тестов, разве?
Мне вот всегда было интересно, чем же руководствуются те, что генерируют спецификацию из кода? Ведь спецификация есть нечто иное, как контракт для взаимодействия между системами, т.е. она должна являться источником истины, а не наоборот.
В реальном мире это можно представить как взаимоотношение, например, клиента и банка. Условия, на которых банк оказываем услуги (не обнуляет ваши счета, начисляет проценты по вкладам и так далее) зависели бы от того, как банк фактически обходится с вашими средствами, а не от того, на каких условиях вы заключили с ним контракт (договор, условия обслуживая и т.п.).
Борис, вы безусловно большой молодец, что разобрались со своим кейсом и поделились опытом! Но мне вот просто интересно - почему бы не описать спецификацию в yaml/json формате, и из неё уже сгенерировать код под Echo сервер используя, например, deepmap/oapi-codegen? Вносить изменения будет так же просто - изменили спеку (контракт), сгенерировали соответствующий код, поправили имплементацию. Но правило источника истины в этом случае сохраняется, и бережёт вас же от обратно-несовместимых изменений, и значительно упрощает ревью. Да и кода будет меньше, и поддерживать 3rd party решение вам не придётся.
Сперва - полноценный тест, потом - в релиз :) Сможете и PR бабахнуть с юзкейсами, если не сложно. Хорошего дня вам!
Домен-то такой мы завести можем, а вот certbot начинает ругаться:
Так что пользуемся
*.x-docker.indocker.app:Релизнуто в v1.1.1. Играйтесь на здоровье, как будет чем поделиться - сюда или в личку черканите, пожалуйста :3
Интересное предложение. Давайте так - я могу для вас (теста для) зону завести, скажем, вида
*.__habr_sabmaks__.indocker.app, которая будет резольвится в172.17.0.1. Вы сможете вдоволь наиграться, а после этого поделиться обратной связью. Если подводных комней не встретите (или элегантно их обойдёте) - то конечно впилим это как перманентную фичуПростите меня, но удержаться было слишком сложно
Ответили ровно так, как бы сам и написал, благодарю :3
Спасибо за теплый отзыв!
Речь только о локальном окружении, повторюсь. Вот есть у вас, к примеру, сервис (и не редко не один), что состоит из фронтенда и нескольких бэкэндов, и все они разрабатываются с использованием докера. Чтоб с ними взаимодействовать локально вам, скорее всего надо будет пробросить их порты в хост (обращаясь к ним
127.0 0.1:8080,127.0.0.1:8081и так далее). И вот вопрос - что для вас удобнее - держать в голове что и на каком порту крутится, или использовать "человеческие" доменные имена видаapi.indocker.app,web.indocker.appи тому подобные? Да чтоб еще и tls сертификат был из коробки для них, валидный всюду? Вот статья как раз про это :) Ничего никуда не привязывается, так как работает исключительно на вашей машине, и работает везде, где есть возможность запустить демон докера; под окнами, линуксом и маком, под amd и arm. Так стало понятнее? Извиняюсь, что не удалось это сразу отразить в статье. Видимо, "глаз уже замылился" несколькоВ теории, наверное, можно, но не делал так никогда. Если у вас есть опыт и сценарий автоматизации этого - поделитесь?
В hosts прописывать желание пропало после второго раза. Ровно как и держать локальный резольвер типа dnsmasq на зону. Ты же не один работаешь, а всех в командах учить этому, да на зоопарке систем - совсем печаль-тоска. Да, забыл уточнить в статье - ttl у dns записей, что указывают на локалхост - одни сутки. Так что если моргнет сеть на пару часов, и ttl не игнорится локальным кэшем - проблем не должно быть.
Для совсем локальных историй есть mkcert (ссылка на него есть в статье), но это опять-таки телодвижения :)
Для однотипных проектов давно придуман boilerplate, но придумать проблему и мужественно ее решить - тоже отдельный вид искусства, согласен (извиняюсь за токсичность)
И еще одна крохотная ремарка - не используйте bash, там где без него "ну никак". В частности, в
restartSwapон ну совсем лишнийСпасибо за статью! Но почему интерфейс калькулятора имеет вид
А не:
Или я проморгал сакральный смысл?
Спасибо Дане за счастливое детство и сломанную психику <3
Но поиграться с тем же Lua мне было бы интересно, спасибо за идею
Полностью поддерживаю комментатора выше, 3proxy отличный выбор из категории "запустил и забыл" (написан на C).
Для его запуска в докере, пару лет назад создал образ с entrypoint скриптом, который заведует конфигом авторизации - никакой дополнительный конфиг даже пробрасывать внутрь контейнера не надо.
Спасибо за ваш комментарий! Не со всем согласен, кое-что перепроверю, но за зашу обратную связь и развернутую мысль - огромное спасибо!