1) у вас на схеме идёт от одной базы связь к другой из продакшена в test, что это значит?
Там показана связь от сервиса "Backend API" в окружении "dev" до двух баз: в "prod" и в "dev". Строго говоря, это не совсем верно, поскольку окружения должны быть полностью изолированные.
Во время разработки и тестирования новых версий backend-а иногда было полезно сходить в продовую базу, поэтому связь осталась в конфигах и на схеме
2) зачем такая сложная схема с лейблами если образ не был изменён он и не появится соответственно и не обновится. обновиться только те образы которые появились от изменений в коде.
Предполагаю, речь про лейблы в пайплайнах репозиториев backend/frontend.
Нет, в текущей реализации сборка образа не зависит от наличия или отсутствия изменений в коде. Можно собрать два одинаковых образа на базе одного и того же кода, но они будут иметь разные теги
Иногда нет необходимости собирать образ на каждый коммит. В таком случае лейбл сборки можно отключить и добавить только в тот момент, когда реально потребуется собрать образ для выкатки
3) в какой момент происходит обновление продакшена - это ручное нажатие скрипта? Обновиться абсолютно весь production (для того чтобы ваше лейблы были одинаковой версии) или только те сервисы которые изменились?
Есть 3 триггера для запуска джобы деплоя продакшена
Лейбл prod-deploy на MR.
Ручной запуск джобы в MR
Merge в main-ветку. При мердже в main-ветку автоматически запускается джоба prod-deploy.
При запуске сервисы деплоятся с теми версиями, которые указаны в конфиге. Если версия не поменялась, сервис не перезапускается. Если поменялась - обновляется
4) Как происходит замена тестового окружения если нужно откатить изменения в том числе на старую базу данных?
Аналогично выкатке, но вместо более новой версии указывается более старая. Автоматизации управления содержимым БД в моей реализации нет, тут нужно будет обновлять вручную.
Большое спасибо за такой подробный и развернутый комментарий!
В вашем проекте вы используете nginx - однако, насколько я знаю, он резолвит доменные имена при старте и, если IP сервиса меняется - то он об этом не узнает. Если вы обновляете frontend - то приходится и nginx тоже рестартовать?
В моём случае всё крутится на одном сервере, пеезжать пока не приходилось. Так что все адреса, можно сказать, постоянные.
Нет, при обновлении frontend'а nginx-proxy не нужно рестартить. Он так же продолжает перенаправлять соответствующий трафик на фронтовый сервис.
Вы выставляете порты для базы данных наружу - это очень небезопасно. Тем более что они доступны по всем интерфейсам хоста. Тем более это не нужно в overlay сетях - сервисы прекрасно найдут базу внутри swarm.
Согласен. Порт был открыт именно из-за необходимости периодически подключаться к базе напрямую. Про то, что сервисы базу внутри swarm найдут и без этого - знаю.
Вы можете возразить что вам нужно к ней иногда подключаться, но для этого можно придумать промежуточный временный контейнер, который подключится одним концом к базе, а порт прокинет наружу - только на localhost и только в моменты когда вам это нужно. Можно сделать его на socat, и можно просто на ssh tunnel.
Не знал про такие решения. Приму на вооружение, спасибо!
Предположу, что в комментарии речь шла именно про скорость переключения между страницами/закладками. Безусловно, в электронной книге можно оставлять закладки/пометки, однако скорость навигации по ним зачастую будет ниже, чем в бумажной книге
Для той аудитории для которой вы пишите скорей всего своим/обычным будет пользователь root.
Почему? В Linux, наоборот, не рекомендуется (раз , два, три) без надобности работать от имени root-пользователя. Для большинства своим/обычным пользователем наверняка будет как раз собственный пользователь, созданный при установке системы (или в процессе её использования), а не root.
Можно ли сгенерировать ssh-ключи от root'а? Можно. Зачем?
Рекомендую генерировать под своим пользователем. Не совсем понимаю, зачем в данном случае генерировать их с правами супер-пользователя (от пользователя root)
А почему в host и hostname нужно указывать одинаковое значение?
Hostname - реальное имя хоста, на который мы обращаемся (github.com, например)
Host - в каком-то роде "псевдоним". Да, он может отличаться от Hostname, но тогда все URI-адреса, идентифицирующие удалённые репозитории, должны будут содержать его вместо реального адреса.
Т.е. можно в конфиге задать:
Host myhost
HostName github.com
User git
IdentityFile ~/.ssh/personal_key
IdentitiesOnly yes
но тогда и удалённые репозитории будут иметь адреса вида git@myhost:username/reponame.git.
Зачем это нужно, если для получения доступа используется один ключ, мне не понятно. В этом случае, на мой взгляд, логичнее задать в Host реальный адрес хоста, чтобы:
Не создавать путаницу
При клонировании репозиториев, например, с GitHub использовать стандартные адреса вида git@github.com:username/reponame.git и не иметь проблем.
А как настроить доступ к разным репозиториям GitHub с разными ключам?
На практике пока не сталкивался с такой задачей.
Во-первых, этот вопрос рассмотрен в статье "How to Manage Multiple SSH Keys", перевод которой я указал в своей статье. А именно - через настройку git'а:
Во-вторых, предположу, что также можно при помощи упомянутых ранее настроек в ssh-конфиге:
Host host_1
HostName github.com
User git
IdentityFile ~/.ssh/key_1
IdentitiesOnly yes
Host host_2
HostName github.com
User git
IdentityFile ~/.ssh/key_2
IdentitiesOnly yes
Первый репозиторий будет иметь адрес git@host_1:user/repo_1.git и к нему мы будем получать доступ при помощи первого ключа. Второй репозиторий будет иметь адрес git@host_2:user/repo_2.git и к нему мы будем получать доступ при помощи второго ключа.
А зачем вы написали статью в которой информации меньше чем в справке GitHub по настройке подключения SSH?
Потому что я хотел написать краткий и практико-ориентированный туториал по тому, как настроить ssh-подключение.
По поводу комбинации Ctrl + U. В bash она действительно стирает всё от курсора до начала строки. В zsh по-умолчанию стирает всю строку. Если нужно, данное поведение можно изменить в .zshrc.
Да, немного экспериментировал с i3, однако тогда не хватило времени, глубины знаний и опыта, чтобы настроить всю систему под свои нужды. Пока пользуюсь KDE c "i3-like" горячими клавишами (переключение рабочих столов, перемещение и закрытие окон, открытие приложений). Сама концепция тайлинговых оконных менеджеров и i3 в частности мне очень нравится. Надеюсь, дойдут руки настроить систему с ним
Спасибо!
Схемы нарисованы в https://app.diagrams.net/
Там показана связь от сервиса "Backend API" в окружении "dev" до двух баз: в "prod" и в "dev". Строго говоря, это не совсем верно, поскольку окружения должны быть полностью изолированные.
Во время разработки и тестирования новых версий backend-а иногда было полезно сходить в продовую базу, поэтому связь осталась в конфигах и на схеме
Предполагаю, речь про лейблы в пайплайнах репозиториев backend/frontend.
Нет, в текущей реализации сборка образа не зависит от наличия или отсутствия изменений в коде. Можно собрать два одинаковых образа на базе одного и того же кода, но они будут иметь разные теги
Иногда нет необходимости собирать образ на каждый коммит. В таком случае лейбл сборки можно отключить и добавить только в тот момент, когда реально потребуется собрать образ для выкатки
Есть 3 триггера для запуска джобы деплоя продакшена
Лейбл prod-deploy на MR.
Ручной запуск джобы в MR
Merge в main-ветку. При мердже в main-ветку автоматически запускается джоба prod-deploy.
При запуске сервисы деплоятся с теми версиями, которые указаны в конфиге. Если версия не поменялась, сервис не перезапускается. Если поменялась - обновляется
Аналогично выкатке, но вместо более новой версии указывается более старая. Автоматизации управления содержимым БД в моей реализации нет, тут нужно будет обновлять вручную.
Большое спасибо за такой подробный и развернутый комментарий!
В моём случае всё крутится на одном сервере, пеезжать пока не приходилось. Так что все адреса, можно сказать, постоянные.
Нет, при обновлении frontend'а nginx-proxy не нужно рестартить. Он так же продолжает перенаправлять соответствующий трафик на фронтовый сервис.
Согласен. Порт был открыт именно из-за необходимости периодически подключаться к базе напрямую. Про то, что сервисы базу внутри swarm найдут и без этого - знаю.
Не знал про такие решения. Приму на вооружение, спасибо!
Спасибо за замечание! Работу моих скриптов это не ломает, поскольку везде явно указываются пути до файлов. На будущее буду иметь в виду
Предположу, что в комментарии речь шла именно про скорость переключения между страницами/закладками. Безусловно, в электронной книге можно оставлять закладки/пометки, однако скорость навигации по ним зачастую будет ниже, чем в бумажной книге
Да, к сожалению, такова специфика электронных книг. Мне тоже это доставляет некоторые неудобства, но я не знаю, как это можно было бы исправить.
Почему?
В Linux, наоборот, не рекомендуется (раз , два, три) без надобности работать от имени
root-пользователя. Для большинства своим/обычным пользователем наверняка будет как раз собственный пользователь, созданный при установке системы (или в процессе её использования), а неroot.Можно ли сгенерировать ssh-ключи от root'а? Можно. Зачем?
Рекомендую генерировать под своим пользователем. Не совсем понимаю, зачем в данном случае генерировать их с правами супер-пользователя (от пользователя
root)Спасибо за дополнение!
Про такой короткий способ переименования файлов, честно признаюсь, не знал. Спасибо
Hostname- реальное имя хоста, на который мы обращаемся (github.com, например)Host- в каком-то роде "псевдоним". Да, он может отличаться отHostname, но тогда все URI-адреса, идентифицирующие удалённые репозитории, должны будут содержать его вместо реального адреса.Т.е. можно в конфиге задать:
но тогда и удалённые репозитории будут иметь адреса вида
git@myhost:username/reponame.git.Зачем это нужно, если для получения доступа используется один ключ, мне не понятно. В этом случае, на мой взгляд, логичнее задать в
Hostреальный адрес хоста, чтобы:Не создавать путаницу
При клонировании репозиториев, например, с GitHub использовать стандартные адреса вида
git@github.com:username/reponame.gitи не иметь проблем.На практике пока не сталкивался с такой задачей.
Во-первых, этот вопрос рассмотрен в статье "How to Manage Multiple SSH Keys", перевод которой я указал в своей статье. А именно - через настройку git'а:
Во-вторых, предположу, что также можно при помощи упомянутых ранее настроек в ssh-конфиге:
Первый репозиторий будет иметь адрес
git@host_1:user/repo_1.gitи к нему мы будем получать доступ при помощи первого ключа. Второй репозиторий будет иметь адресgit@host_2:user/repo_2.gitи к нему мы будем получать доступ при помощи второго ключа.Потому что я хотел написать краткий и практико-ориентированный туториал по тому, как настроить ssh-подключение.
Большое спасибо за рекомендации!
Спасибо за рекомендации!
По поводу затрат времени на настройку и поддержку - думаю, это личное дело каждого. Я лишь рассказал о том, как всё настроено лично у меня
Спасибо за замечания!
По поводу комбинации
Ctrl + U. В bash она действительно стирает всё от курсора до начала строки. В zsh по-умолчанию стирает всю строку. Если нужно, данное поведение можно изменить в.zshrc.Да, немного экспериментировал с i3, однако тогда не хватило времени, глубины знаний и опыта, чтобы настроить всю систему под свои нужды. Пока пользуюсь KDE c "i3-like" горячими клавишами (переключение рабочих столов, перемещение и закрытие окон, открытие приложений). Сама концепция тайлинговых оконных менеджеров и i3 в частности мне очень нравится. Надеюсь, дойдут руки настроить систему с ним