1. Введение
Если мы оглянемся на ряд проблем, связанных с микросервисной архитектурой , то, вероятно, одна из самых трудных проблем — это то, что каждый микросервис может говорить на правильном языке с каждым из своих партнеров. В последнее время мы много говорили о тестировании, но всегда есть возможность проникнуть в ошибки. Может быть, это изменения в договорах в последнюю минуту? Или, может быть, требования безопасности ужесточены? А как насчет непреднамеренного подталкивания неправильной конфигурации?
Чтобы решить эти проблемы, наряду со многими другими, мы собираемся поговорить о практике непрерывной интеграции и непрерывной доставки . Так что же это за практики, насколько они полезны и в чем их различие?
Содержание
Парадигма непрерывной интеграции требует, чтобы ваши изменения как можно чаще помещались в основной репозиторий исходного кода в сочетании с выполнением полной сборки и выполнением набора автоматических тестов и проверок. Цель здесь — постоянно поддерживать сборки и проходить тесты, избегая сценария, когда все пытаются объединить изменения в последний момент, затягивая проект в ад интеграции.
Практика непрерывной доставки поднимает непрерывную интеграцию на новый уровень, обеспечивая автоматизацию процесса выпуска и гарантируя, что проекты готовы к выпуску в любое время. Удивительно, но не многие организации понимают важность непрерывной доставки , но эта практика является абсолютно необходимой предпосылкой, чтобы следовать принципам микросервисной архитектуры .
Честно говоря, непрерывная доставка это еще не конец. Процесс непрерывного развертывания замыкает цикл, предоставляя поддержку автоматического развертывания релизов прямо в работающей системе. Наличие постоянного развертывания является показателем зрелого развития организации.
2. Дженкинс
Для многих термин « непрерывная интеграция» сразу вспоминает Дженкинса . Действительно, это, вероятно, одна из наиболее распространенных платформ непрерывной интеграции (и непрерывной доставки ), особенно в экосистеме JVM.
Jenkins — это автономный сервер автоматизации с открытым исходным кодом, который можно использовать для автоматизации всех видов задач, связанных со сборкой, тестированием и поставкой или развертыванием программного обеспечения. — https://jenkins.io/doc/
У Дженкинса есть интересная история, которая по существу порождает два радикально разных лагеря: тех, кто ненавидит это, и тех, кто любит это. К счастью, выпуск версии 2.0 Jenkins несколько лет назад стал настоящим переломным моментом в игре, в которой цунами инноваций.
Чтобы проиллюстрировать мощь Jenkins , давайте взглянем на то, как платформа JCG Car Rentals использует конвейеры для непрерывного построения и тестирования своих микросервисных проектов.
Истинная жемчужина Jenkins — это его расширяемость и огромное количество доступных плагинов для сообщества. Как вы, наверное, помните, все проекты JCG Car Rentals интегрируются с SpotBugs для статического анализа кода и проверки зависимостей OWASP для выявления уязвимых зависимостей. Неудивительно, что у Jenkins есть плагины для обоих, которые легко внедряются в конвейер сборки, как один из сервисов поддержки клиентов .
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
pipeline { agent any options { disableConcurrentBuilds() buildDiscarder(logRotator(numToKeepStr:'5')) } triggers { pollSCM('H/15 * * * *') } tools { jdk "jdk-8u202" } stages { stage('Cleanup before build') { steps { cleanWs() } } stage('Checkout from SCM') { steps { checkout scm } } stage('Build') { steps { withMaven(maven: 'mvn-3.6.0') { sh "mvn clean package" } } } stage('Spotbugs Check') { steps { withMaven(maven: 'mvn-3.6.0') { sh "mvn spotbugs:spotbugs" } script { def spotbugs = scanForIssues tool: [$class: 'SpotBugs'], pattern: '**/target/spotbugsXml.xml' publishIssues issues:[spotbugs] } } } stage('OWASP Dependency Check') { steps { dependencyCheckAnalyzer datadir: '', hintsFile: '', includeCsvReports: false, includeHtmlReports: true, includeJsonReports: false, includeVulnReports: false, isAutoupdateDisabled: false, outdir: '', scanpath: '', skipOnScmChange: false, skipOnUpstreamChange: false, suppressionFile: '', zipExtensions: '' dependencyCheckPublisher canComputeNew: false, defaultEncoding: '', healthy: '', pattern: '', unHealthy: '' } } } post { always { archiveArtifacts artifacts: 'target/*.jar', fingerprint: true archiveArtifacts artifacts: '**/dependency-check-report.xml', onlyIfSuccessful: true archiveArtifacts artifacts: '**/spotbugsXml.xml', onlyIfSuccessful: true } }} |
После запуска конвейерного задания в Jenkins отчеты о проверках зависимостей SpotBugs и OWASP публикуются как часть результатов сборки.
Чрезвычайно важно сохранять дисциплину и следовать принципам непрерывной интеграции . Сборки должны быть здоровыми и проходящими все время.
Есть много вещей, которые можно сказать о Jenkins , особенно в отношении его интеграции с Docker, но давайте лучше рассмотрим другие варианты.
3. SonarQube
Мы говорили о SonarQube в предыдущих частях урока . Справедливости ради, он не вписывается в непрерывную интеграцию или непрерывную доставку, а скорее является дополнительной, непрерывной проверкой качества кода.
SonarQube — это платформа с открытым исходным кодом для автоматического анализа со статическим анализом кода для обнаружения ошибок, запахов кода и уязвимостей в безопасности на более чем 25 языках программирования, включая Java, C #, JavaScript, TypeScript, C / C ++, COBOL и другие . … — https://www.sonarqube.org/about/
Результаты квалификационных проверок кода SonarQube имеют огромное значение. Чтобы взглянуть на них, давайте взглянем на панель управления качеством кода обслуживания клиентов .
Как вы можете видеть, существует некоторое пересечение с отчетами, сгенерированными SpotBugs и OWASP-проверкой зависимостей , однако проверки SonarQube намного шире по объему. Но насколько сложно сделать SonarQube частью ваших конвейеров непрерывной интеграции ? Это настолько просто, насколько это возможно, поскольку SonarQube имеет выдающуюся интеграцию с Apache Maven , Gradle и даже Jenkins .
При поддержке более 25 языков программирования SonarQube , безусловно, поможет вам повысить планку качества кода и удобства сопровождения для всего парка микросервисов (даже если может не быть встроенной интеграции с платформой непрерывной интеграции по вашему выбору).
4. Базель
Базель вышел из Google как разновидность инструмента, который используется для внутреннего создания серверного программного обеспечения компании. Он не предназначен для использования в качестве основы непрерывной интеграции, а служит инструментом для его создания.
Bazel — это инструмент для сборки и тестирования с открытым исходным кодом, аналогичный Make , Maven и Gradle . Он использует понятный человеку язык сборки высокого уровня. Bazel поддерживает проекты на нескольких языках и создает выходные данные для нескольких платформ. Bazel поддерживает большие кодовые базы в нескольких репозиториях и большое количество пользователей. — https://docs.bazel.build/versions/master/bazel-overview.html
Что интересно в Bazel, так это его ориентация на более быстрые сборки (расширенное локальное и распределенное кэширование, оптимизированный анализ зависимостей и параллельное выполнение), масштабируемость (обрабатывает кодовые базы любого размера, во многих репозиториях или огромном монорепо) и поддержку нескольких языков (Java). входит в комплект). В мире микросервисов полиглотов использование такого же инструмента для сборки может быть весьма выгодным.
5. Buildbot
По сути, Buildbot — это система планирования заданий, которая поддерживает распределенное параллельное выполнение заданий на нескольких платформах, гибкую интеграцию с различными системами контроля версий и расширенные отчеты о состоянии заданий.
Buildbot — это среда с открытым исходным кодом для автоматизации процессов сборки, тестирования и выпуска программного обеспечения. — https://buildbot.net/
Buildbot хорошо подходит для удовлетворения потребностей приложений на разных языках (таких как микросервисы polyglot). Он написан на Python и широко использует скрипты Python для задач конфигурации.
6. Зал CI
Concourse использует универсальный подход к автоматизации, что делает его подходящим для поддержки непрерывной интеграции и, в частности, непрерывной доставки .
Concourse — это постоянная работа с открытым исходным кодом. — https://concourse-ci.org/
Все в Concourse работает в контейнере, с ним очень легко начать работу, и его основные принципы проектирования поощряют использование декларативных конвейеров (которые, честно говоря, сильно отличаются от Jenkins или GoCD ). Например, базовый конвейер для обслуживания клиентов может выглядеть так:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
resources: - name: customer-service type: git source: uri: branch: masterjobs: - name: build plan: - get: customer-service trigger: true - task: compile config: platform: linux image_resource: type: docker-image source: repository: maven inputs: - name: customer-service outputs: - name: build caches: - path: customer-service/.m2 run: path: sh args: - -c - mvn -f customer-service/pom.xml package -Dmaven.repo.local=customer-service/.m2 |
Кроме того, Concourse поставляется с инструментами командной строки и довольно простым веб-интерфейсом, который, тем не менее, помогает визуализировать ваши конвейеры, как показано на рисунке ниже.
7. Гитлаб
Gitlab — это полноценная платформа для комплексной разработки программного обеспечения с открытым исходным кодом со встроенным контролем версий, отслеживанием ошибок, проверкой кода, непрерывной интеграцией и непрерывной доставкой .
GitLab — это единое приложение для всего жизненного цикла разработки программного обеспечения. От планирования проекта и управления исходным кодом до CI / CD, мониторинга и безопасности. — https://about.gitlab.com/
Если вы ищете универсальное решение, которое может быть размещено в автономном режиме или управляться в облаке, Gitlab , безусловно, подойдет для этого. Давайте посмотрим на развитие проекта обслуживания клиентов в случае выбора Gitlab .
Непрерывная интеграция и конвейеры непрерывной доставки довольно расширяемы и по умолчанию включают как минимум 3 этапа: сборка, тестирование и качество кода.
Стоит отметить, что Gitlab используется довольно большим количеством компаний, и его популярность и распространение постоянно растут.
8. GoCD
Следующая тема, о которой мы поговорим, GoCD , возникла из ThoughtWorks , организации, широко известной тем, что в ней работают эксперты мирового уровня, в основном, во всех областях разработки программного обеспечения.
GoCD — это инструмент для сборки и выпуска с открытым исходным кодом от ThoughtWorks . GoCD поддерживает современную инфраструктуру и помогает предприятиям получать программное обеспечение быстрее, безопаснее и надежнее. — https://www.gocd.org/
Неудивительно, что конвейеры также являются центральной частью GoCD . Они служат в качестве представления рабочего процесса или части рабочего процесса. Веб-интерфейс GoCD довольно интуитивно понятен, прост и удобен в использовании. Конвейер обслуживания клиентов на изображении ниже является хорошей демонстрацией этого.
Сам конвейер может включать в себя произвольное количество этапов, например, один из этапов обслуживания клиентов имеет два настроенных этапа, Build и Test . Выделенный вид демонстрирует выполнение каждого этапа в мельчайших деталях.
Конвейеры GoCD очень универсальны и не ориентированы на какой-либо язык программирования или платформу разработки, как таковые, для удовлетворения потребностей проектов микросервисов полиглот.
9. CircleCI
Если самостоятельные (или, иначе говоря, локальные) решения не соответствуют вашим планам, существует немало предложений SaaS . CircleCI — один из популярных вариантов.
Платформа непрерывной интеграции и доставки CircleCI позволяет командам любого размера быстро создавать и выпускать качественное программное обеспечение в масштабе. Сборка для Linux, macOS и Android, в облаке или за брандмауэром. — https://circleci.com/
Помимо того, что это отличный продукт, одной из причин, по которой CircleCI включен в наш список, является наличие бесплатного уровня, позволяющего быстро начать работу.
10. TravisCI
TravisCI входит в ту же группу предложений SaaS, что и CircleCI, но с одним важным отличием — оно всегда бесплатно для проектов с открытым исходным кодом.
Travis CI — это система непрерывной интеграции и развертывания. — https://github.com/travis-ci/travis-ci
TravisCI , вероятно, самый популярный сервис непрерывной интеграции, используемый для создания и тестирования программных проектов, размещенных на GitHub . С другой стороны, будущее TravisCI неясно, поскольку он был приобретен в январе 2019 года частной инвестиционной фирмой, и, как сообщается, первоначальная команда разработчиков была уволена .
11. CodeShip
CodeShip — это еще один SaaS для непрерывной интеграции и непрерывной доставки , приобретенный недавно CloudBees , который также предлагает бесплатный план.
Codeship — это быстрый и безопасный сервис непрерывной интеграции, который соответствует вашим потребностям. Он поддерживает проекты GitHub , Bitbucket и Gitlab . — https://cms.codeship.com/
Одним из отличительных преимуществ CodeShip является то, что буквально не требуется (или мало) времени для его настройки и начала работы.
12. Спинакер
Большинство вариантов, которые мы обсуждали до сих пор, пытаются охватить непрерывную интеграцию и непрерывную доставку под одним и тем же зонтиком. С другой стороны, Spinnaker , первоначально созданный в Netflix , фокусируется исключительно на непрерывной доставке вещей.
Spinnaker — это многопотоковая платформа непрерывной доставки с открытым исходным кодом, позволяющая с высокой скоростью и достоверностью сообщать об изменениях программного обеспечения. — https://www.spinnaker.io/
Это действительно уникальное решение, которое сочетает в себе гибкое управление конвейером непрерывной доставки и интеграцию с ведущими поставщиками облачных услуг.
13. Облако
Размещение собственной непрерывной интеграции и инфраструктуры непрерывной доставки может оказаться далеко за пределами вашего кошелька. Предложения SaaS, о которых мы говорили, могут значительно ускорить адаптацию и снизить первоначальные затраты, по крайней мере, когда вы только начинаете. Однако, если вы находитесь в облаке (что более вероятно в наши дни), имеет смысл воспользоваться предложениями, которые облачный провайдер предлагает вам. Давайте посмотрим, что придумали лидеры облачных вычислений .
Первый в нашем списке наверняка AWS , который имеет два предложения, связанных с непрерывной интеграцией и непрерывной доставкой , AWS CodeBuild и AWS CodePipeline соответственно.
AWS CodeBuild — это полностью управляемая служба непрерывной интеграции, которая компилирует исходный код, запускает тесты и создает пакеты программного обеспечения, которые готовы к развертыванию. С CodeBuild вам не нужно выделять , управлять и масштабировать свои собственные серверы сборки. … — https://aws.amazon.com/codebuild/
AWS CodePipeline — это полностью управляемая служба непрерывной доставки, которая помогает автоматизировать ваши конвейеры выпуска для быстрых и надежных обновлений приложений и инфраструктуры. CodePipeline автоматизирует фазы сборки, тестирования и развертывания вашего процесса выпуска каждый раз, когда происходит изменение кода в зависимости от выбранной вами модели выпуска. … — https://aws.amazon.com/codepipeline/
Переходя к Google Cloud , мы наткнемся на предложение Cloud Build , которое является основой усилий по непрерывной интеграции Google Cloud .
Cloud Build позволяет быстро создавать программное обеспечение на всех языках. Получите полный контроль над определением пользовательских рабочих процессов для создания, тестирования и развертывания в нескольких средах … — https://cloud.google.com/cloud-build/
Microsoft Azure выбрал другой путь и начал с предложения управляемого Дженкинса . Но вскоре после приобретения GitHub появился DevOps Azure , совершенно новое предложение, которое включает непрерывную интеграцию , непрерывную доставку и непрерывное развертывание .
Службы DevOps Azure предоставляют инструменты для совместной разработки, включая высокопроизводительные конвейеры, бесплатные частные Git- репозитории, настраиваемые платы Kanban и широкие возможности автоматического и непрерывного тестирования. …. — https://docs.microsoft.com/en-ca/azure/devops/index?view=azure-devops
14. Cloud Native
Прежде чем закончить, было бы здорово взглянуть на то, как существующие решения для непрерывной интеграции и непрерывной доставки адаптируются к постоянно меняющейся инфраструктуре и операционной среде. В этой области происходит много инноваций, давайте просто рассмотрим несколько интересных событий.
Начнем с того, что Jenkins недавно анонсировал новый подпроект Jenkins X , специально предназначенный для развертываний на базе Kubernetes . Я думаю, что эта тенденция продолжится, и другие игроки наверстают упущенное, так как популярность Kubernetes стремительно растет .
Распространение безсерверной модели выполнения поставило непрерывную интеграцию и непрерывную доставку в новую перспективу. В этом отношении стоит отметить LambCI , систему непрерывной интеграции, построенную на AWS Lambda . Вполне вероятно, что мы увидим больше вариантов на этом фронте.
15. Выводы
Важность непрерывной интеграции в наши дни не вызывает вопросов. С другой стороны, постоянные поставки и непрерывное развертывание отстают, но они, несомненно, являются неотъемлемой частью принципов микросервиса .
В этом разделе руководства мы рассмотрели множество вариантов, но, очевидно, в дикой природе есть и много других. Упор делается не на конкретное решение, а на сами практики. Поскольку вы отправились в путешествие по микросервисам , вы также обязаны сделать его гладким.
16. Что дальше
В следующем разделе учебного курса мы собираемся подробнее разобраться с эксплуатационными проблемами, связанными с архитектурой микросервиса, и поговорим об управлении конфигурацией, обнаружении служб и балансировке нагрузки.