Мы развернули два докер-контейнера в одной сети и указываем для контейнера дженкинса переменную среды DOCKER_HOST=tcp://docker:2376 ("docker" - это alias контейнера docker:dind). Эта настройка говорит дженкинсу использовать докер на удаленной машине. Данные для сборки в docker:dind присутствуют, так как к обоим контейнерам примонтирован один и тот же вольюм с данными - jenkins-data.
А такой подход как долго у вас практикуется на проде? Большая ли команда и проект? Ресурс публичный или внутрикорпоративный? Какая нагрузка?
В свое время я активно работал с компонентными фреймворками (Wicket, Zk), и статья выглядит как переоткрытие этого подхода. По моему опыту он подходит разве что для админок или прототипов. Огромный мемори футпринт на каждого пользователя из-за хранения состояния виджетов/страниц на бэке, боль из-за попыток реализовать богатое поведение веба, огромное количество коллбеков с фронта, спаггети код из-за смешения фронтовой и бэковской логики (наверное этого можно избежать, но неизбежно кодовая база разрастается нещадно из-за того, что все теперь хранится только на бэке). Имхо в статье server-side подход представлен очень однобоко, негативные моменты, как мне кажется, не были должным образом освещены. Сходу выглядит, как серебряная пуля:) Но статья интересная, еще раз спасибо за ваш труд)
В команде ADD первым аргументом передается директория на локальной машине, а вторым — в образе. Я согласен, что во избежание путаницы стоило назвать эту папку как-нибудь по-другому (№ /app).
Докер-файл я перепроверил — он должен работать. Проверьте, что у вас в репозитории в корне присутствует файл mvnw. Если он все же есть, то можно вставить строчку "RUN ls" после "WORKDIR /src" и посмотреть, что представляет из себя рабочая директория в контейнере.
Bitmap Index Scans объединяет оба случая: когда вам нужно много строк из таблицы, но не все, и когда строки, которые вы будете возвращать, находятся не в одном блоке (что было бы оправдано, если бы я производил операцию “… where id < ...").
Можете пояснить, что имеется в виду под "находятся не в одном блоке"? Ведь по сути индекс на id отличается от индекса на i только ограничением на уникальность. Или играет роль, то что мы добавляем строки, монотонно увеличивая id?
Сначала тестируем все локально мавеном. Если все ок, то создаем ветку для задачи, коммитим изменения. Jenkins видит это, тестирует наш коммит. Мы видим результат, и в случае успеха делаем PR
Спасибо за разъяснения. Соглашаюсь с тем, что в пайплайне образ должен формироваться из собранных бинарников. Обязательно сделаю на этом акцент в дальнейшем.
В моем понимании, когда разработчик пушит что-то в гит, тогда его ветка и должна быть протестирована. А давать возможность разработчику по сути вручную отправлять образ тестироваться — не вижу особого смысла в этом. Но, видимо, это просто альтернативный подход к организации рабочего процесса.
Содержимое статьи не менялось с момента публикации (не считая опечатки, маленькие правки). Видимо, стоило более явно акцентировать, что первый Dockerfile "в лоб" применяться не должен. Внесу правку
Автор либо гений, либо шарлатан (почему-то вспомнилась бизнес молодость).
Посмотрел GitHub — вплоть до 18 года идут коммиты почти только в приватные репозитории (причем много коммитов). Зачем начинающему разработчику делать свои репозитории приватными? Ради объективности отмечу, что некоторые коммиты с кодом были — но это по сути пара скриптов в сумме и редкие коммиты с хорошим, документированным кодом на js (насколько могу судить). Но все же основная активность юзера — создание форков, коммиты в 1-2 строчки (в основном корректировки html и изменения версий/конфигов). Первый коммит в skyeng — октябрь 19 года. Там также по сути изменения в README, кода не наблюдаю. С этого момента коммиты в закрытые репозитории можно объяснить (NDA).
Итого имеем очень странный GitHub, в котором всего пара проектов с написанным кодом, а все остальное непонятно что. Куча мизерных коммитов, чередующихся с кучей коммитов в приватные репозитории. А кода то по факту нет.
Также в глаза бросается прямо дикая активность молодого человека во всех возможных сетях. Зачем такой активный самопиар увлеченному разработчику?
Но, повторюсь, возможно я не прав, и автор гений. Надеюсь это так.
Спасибо за комментарий.
Я полностью с вами согласен в том, что инструменты непрерывной интеграции наподобие Jenkins необходимы. Без хорошего пайплайна организовать эффективную работу с микросервисами вряд ли возможно. Создание такого пайплайна я попробую описать в 3 статье этой серии.
Однако не могу согласиться с таким использованием Maven. В моем понимании, Maven должен выступать исключительно инструментом сборки и тестирования проекта, но не деплоя, так как является в первую очередь инструментом разработчика, а не devops-инженера. Для того чтоб запушить образ в докер-репозиторий, плагину необходимо предоставить как минимум пароли. Вероятно это делается через переменные среды. Разработчикам эти пароли недоступны, соответственно для них команда mvn deploy закрыта. Так зачем же тогда нагружать этим проект? И как обеспечить увеличение версии (тега) образа — также передавать извне?
Честно сказать, мне не пришлось поработать в проектах, где Maven использовался бы так, как вы описали. Может быть в этом подходе есть что-то, что я упускаю?
Если мы говорим про авторизацию в микросервисах, то частый способ — это использование JWT-токенов. Пользователь логинится, получает токен и далее шлет его с каждым запросом в заголовке или куке. Далее этот токен передается между сервисами, позволяя авторизовывать пользователя непосредственно в каждом сервисе.
В фрагменте, который вы привели, я имел в виду изоляцию сервиса в рамках одной сети. Эта возможность может быть предоставлена облачным провайдером (№ VPC), либо же в других случаях настроена вручную (локальная сеть, VPN). Основной момент во всех решениях — для пользователя извне должен быть доступен только шлюз.
При использовании многошагового билда в итоговый Docker образ исходники включены не будут. На шаге 1 (он помечен как 'builder') выполняется сборка приложения, и генерируется jar-архив /src/target/microservices-backend-1.0.0.jar.
На 3 шаге мы копируем только этот jar-архив в итоговый образ:
При формировании образа докер удалит все файлы, относящиеся к промежуточным шагам и не скопированные нами в итоговый образ явно. В итоге в конечном образе у нас будут только файлы из базового образа, jar-архив и JRE из шага 2.
Спасибо за комментарий. В статье описаны два Dockerfile — один наиболее примитивный и как раз multi-stage Dockerfile. Насколько могу судить, в итоговый образ не попадут ни maven, ни исходники.
Мы развернули два докер-контейнера в одной сети и указываем для контейнера дженкинса переменную среды DOCKER_HOST=tcp://docker:2376 ("docker" - это alias контейнера docker:dind). Эта настройка говорит дженкинсу использовать докер на удаленной машине. Данные для сборки в docker:dind присутствуют, так как к обоим контейнерам примонтирован один и тот же вольюм с данными - jenkins-data.
Спасибо за статью!
А такой подход как долго у вас практикуется на проде? Большая ли команда и проект? Ресурс публичный или внутрикорпоративный? Какая нагрузка?
В свое время я активно работал с компонентными фреймворками (Wicket, Zk), и статья выглядит как переоткрытие этого подхода. По моему опыту он подходит разве что для админок или прототипов. Огромный мемори футпринт на каждого пользователя из-за хранения состояния виджетов/страниц на бэке, боль из-за попыток реализовать богатое поведение веба, огромное количество коллбеков с фронта, спаггети код из-за смешения фронтовой и бэковской логики (наверное этого можно избежать, но неизбежно кодовая база разрастается нещадно из-за того, что все теперь хранится только на бэке). Имхо в статье server-side подход представлен очень однобоко, негативные моменты, как мне кажется, не были должным образом освещены. Сходу выглядит, как серебряная пуля:) Но статья интересная, еще раз спасибо за ваш труд)
Аннотация
@Componentне обязательна, т.к. спринг и без нее создаст нужный бинВ команде ADD первым аргументом передается директория на локальной машине, а вторым — в образе. Я согласен, что во избежание путаницы стоило назвать эту папку как-нибудь по-другому (№ /app).
Докер-файл я перепроверил — он должен работать. Проверьте, что у вас в репозитории в корне присутствует файл mvnw. Если он все же есть, то можно вставить строчку "RUN ls" после "WORKDIR /src" и посмотреть, что представляет из себя рабочая директория в контейнере.
Очень полезная статья, спасибо.
Можете пояснить, что имеется в виду под "находятся не в одном блоке"? Ведь по сути индекс на id отличается от индекса на i только ограничением на уникальность. Или играет роль, то что мы добавляем строки, монотонно увеличивая id?
Спасибо за комментарий. Согласен, этот момент с LoadBalancer'ом стоит упомянуть. Дополнил статью
Спасибо, есть над чем подумать
Сначала тестируем все локально мавеном. Если все ок, то создаем ветку для задачи, коммитим изменения. Jenkins видит это, тестирует наш коммит. Мы видим результат, и в случае успеха делаем PR
Спасибо за разъяснения. Соглашаюсь с тем, что в пайплайне образ должен формироваться из собранных бинарников. Обязательно сделаю на этом акцент в дальнейшем.
В моем понимании, когда разработчик пушит что-то в гит, тогда его ветка и должна быть протестирована. А давать возможность разработчику по сути вручную отправлять образ тестироваться — не вижу особого смысла в этом. Но, видимо, это просто альтернативный подход к организации рабочего процесса.
Содержимое статьи не менялось с момента публикации (не считая опечатки, маленькие правки). Видимо, стоило более явно акцентировать, что первый Dockerfile "в лоб" применяться не должен. Внесу правку
Автор либо гений, либо шарлатан (почему-то вспомнилась бизнес молодость).
Посмотрел GitHub — вплоть до 18 года идут коммиты почти только в приватные репозитории (причем много коммитов). Зачем начинающему разработчику делать свои репозитории приватными? Ради объективности отмечу, что некоторые коммиты с кодом были — но это по сути пара скриптов в сумме и редкие коммиты с хорошим, документированным кодом на js (насколько могу судить). Но все же основная активность юзера — создание форков, коммиты в 1-2 строчки (в основном корректировки html и изменения версий/конфигов). Первый коммит в skyeng — октябрь 19 года. Там также по сути изменения в README, кода не наблюдаю. С этого момента коммиты в закрытые репозитории можно объяснить (NDA).
Итого имеем очень странный GitHub, в котором всего пара проектов с написанным кодом, а все остальное непонятно что. Куча мизерных коммитов, чередующихся с кучей коммитов в приватные репозитории. А кода то по факту нет.
Также в глаза бросается прямо дикая активность молодого человека во всех возможных сетях. Зачем такой активный самопиар увлеченному разработчику?
Но, повторюсь, возможно я не прав, и автор гений. Надеюсь это так.
Спасибо за комментарий.
Я полностью с вами согласен в том, что инструменты непрерывной интеграции наподобие Jenkins необходимы. Без хорошего пайплайна организовать эффективную работу с микросервисами вряд ли возможно. Создание такого пайплайна я попробую описать в 3 статье этой серии.
Однако не могу согласиться с таким использованием Maven. В моем понимании, Maven должен выступать исключительно инструментом сборки и тестирования проекта, но не деплоя, так как является в первую очередь инструментом разработчика, а не devops-инженера. Для того чтоб запушить образ в докер-репозиторий, плагину необходимо предоставить как минимум пароли. Вероятно это делается через переменные среды. Разработчикам эти пароли недоступны, соответственно для них команда mvn deploy закрыта. Так зачем же тогда нагружать этим проект? И как обеспечить увеличение версии (тега) образа — также передавать извне?
Честно сказать, мне не пришлось поработать в проектах, где Maven использовался бы так, как вы описали. Может быть в этом подходе есть что-то, что я упускаю?
Если мы говорим про авторизацию в микросервисах, то частый способ — это использование JWT-токенов. Пользователь логинится, получает токен и далее шлет его с каждым запросом в заголовке или куке. Далее этот токен передается между сервисами, позволяя авторизовывать пользователя непосредственно в каждом сервисе.
В фрагменте, который вы привели, я имел в виду изоляцию сервиса в рамках одной сети. Эта возможность может быть предоставлена облачным провайдером (№ VPC), либо же в других случаях настроена вручную (локальная сеть, VPN). Основной момент во всех решениях — для пользователя извне должен быть доступен только шлюз.
При использовании многошагового билда в итоговый Docker образ исходники включены не будут. На шаге 1 (он помечен как 'builder') выполняется сборка приложения, и генерируется jar-архив /src/target/microservices-backend-1.0.0.jar.
На 3 шаге мы копируем только этот jar-архив в итоговый образ:
При формировании образа докер удалит все файлы, относящиеся к промежуточным шагам и не скопированные нами в итоговый образ явно. В итоге в конечном образе у нас будут только файлы из базового образа, jar-архив и JRE из шага 2.