По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
У вас когда-нибудь происходила ситуация, когда вы путешествовали и не могли посмотреть те шоу, которые обычно смотрите дома, на Netflix? Или может вы замечали, что некоторые веб-сайты заблокированы или вы не могли получить к определенным службам, когда подключаетесь к разным сетям Wi-Fi? Вероятно, что это связано с наличием прокси-сервера.
Что такое прокси-сервер?
Прокси-сервер, или просто прокси для краткости, - это как наличие другого компьютера, на который отправляются ваши интернет-запросы перед переходом на настоящий веб-сайт. Это сервер, который принимает всю отправленную вами информацию, например, запрос на покупку новых рубашек H&M, и направляет ее через другой IP-адрес.
Вот что делает прокси таким впечатляющим. Они могут заставить всю вашу интернет-активность выглядеть так, как будто она исходит из совершенно другого места.
Компании используют прокси-серверы для обеспечения безопасности и производительности сети, частные лица – для обеспечения конфиденциальности. Также существуют несколько интересных функций, которые вы можете использовать с прокси при просмотре сети и ресурсов. О них мы поговорим позже.
Прокси может быть физически расположен где угодно. Вы можете настроить его на своем домашнем компьютере или развернуть его в облаке. Главное, чтобы прокси имел конфигурацию, необходимую для нужных вам функций.
Просто помните, что прокси действует как замысловатый фильтр IP-адресов. Как и у фильтров, у прокси также есть множество разновидностей, и все они имеют конкретное применение.
Для начала давайте поговорим о самом распространенном типе прокси и о том, как он работает, - о прокси-сервере переадресации (forward proxy).
Как работает прокси-сервер?
Если вы слышите, как люди говорят о прокси, то с большой долей вероятности они имеют в виде прокси-серверы переадресации. Это самый распространенный тип прокси, потому что он легко справляется с тем, что нужно большинству людей. Прокси-серверы переадресации действуют как посредники между вашими запросами и сервером, к которому вы пытаетесь подключиться.
Прокси работает следующим образом: сначала вы делаете запрос, например, вы пытаетесь перейти на GitHub. Итак, вы вводите URL-адрес и нажимаете Enter. При использовании прокси-сервера он перехватывает ваш запрос вместо того, чтобы напрямую подключать вас к GitHub с IP-адресом вашего компьютера.
Затем прокси принимает ваш запрос, обновляет его и отправляет со своего собственного IP-адреса. Это может полностью удалить ваш IP-адрес и идентифицирующую информацию из запроса к серверу GitHub.
Один из способов, с помощью которого прокси-серверы обрабатывают изменение вашего запроса, заключается непосредственно в заголовках запросов, которые он отправляет на сервер. Прокси-запрос может устанавливать заголовки, такие как Forwarded и Via, в исходном запросе, прежде чем он отправит сообщение на сервер, с которого вы пытаетесь получить информацию.
Как только прокси-сервер обновит информацию из вашего запроса, он отправит ваш переформатированный запрос на сервер GitHub. Теперь этот сервер будет считать, что ваш запрос поступил из другого места, и отправит нужные вам данные обратно через тот же IP-адрес.
Затем прокси-сервер забирает данные с сервера GitHub и выполняет все проверки, которые были настроены для этих данных. Он может проверять на наличие вредоносных скриптов или других проблем с безопасностью. Затем он, наконец, отправляет данные на ваш компьютер, и ваша страница загружается.
Прокси-сервер может использоваться параллельно несколькими пользователями. Несколько человек могут отправлять запросы через один и тот же прокси-сервер, и все они могут использовать его преимущества в равной степени. Есть много причин, по которым вы можете использовать прокси, даже если он общий.
Для чего следует использовать прокси-сервер?
Теперь, когда вы знаете, что такое прокси, полезно будет узнать о некоторых распространенных случаях из применения.
Вы можете повысить безопасность сети, зашифровав запросы.
Предотвратите перехватывание хакерами конфиденциальной информации.
Блокируйте вредоносные сайты из вашей настоящей сети.
Вы можете уменьшить объем сетевого трафика за счет кэширования сайтов.
Кэшируйте веб-сайты для того, чтобы к нему выполнялся только один запрос, независимо от того, сколько пользователей находится на прокси-сервере.
Вы можете контролировать то, как люди используют Интернет.
Блокируйте определенные домены.
Отслеживайте и регистрируйте все веб-запросы.
Вы можете обойти блокировки, установленные компаниями и странами.
Получайте доступ к контенту из другой страны.
Обходите корпоративные брандмауэры.
Это определенно не весь список всего, что вы можете делать с прокси-сервером. Также я хотел упомянуть некоторые другие преимущества, которые не совсем попадают под стандартные категории.
У вас всегда заблокированы файлы cookie.
У вас всегда заблокирована реклама.
Вы можете получить доступ к «глубокой сети».
Он удаляет любые поисковые настройки или отслеживание вашей истории поиска.
Вы можете извлекать данные.
Вы можете изучать своих конкурентов.
Различные типы прокси-серверов
Существует множество типов прокси-серверов, которые охватывают практически любую конфигурацию, которую вы только можете себе представить. Ниже я привел краткий обзор на 14 различных типов прокси.
Прозрачный прокси-сервер (Transparent proxy)
Прозрачный прокси-сервер – это самый простой вид прокси. Они передают все вашу информацию, но с IP-адресом прокси-сервера. Такие прокси не обеспечивают никакой защиты конфиденциальности.
Они сообщают серверу, на который вы отправляете запрос, что запрос поступает через прокси. Этого будет достаточно для того, чтобы обойти простые блокировки IP. Как правило, прозрачные прокси-серверы используют для настройки фильтрации веб-сайтов, например, в школах или компаниях.
Анонимный прокси-сервер (Anonymous proxy)
Анонимный прокси-сервер – это широко используемый тип прокси. Они никогда не передают ваш IP-адрес веб-сайту, который вы просматриваете, хотя в запросе они идентифицируют себя как прокси. Это помогает сохранить конфиденциальность вашей активности в Интернете.
Если вы не хотите, чтобы таргетированная реклама следовала за вами по пятам по всему Интернету, или если вы не хотите, чтобы ваше местоположение было привязано к вашему запросу, то можно использовать такие стандартные прокси. Обычно их достаточно для того, чтобы обойти большинство действий таргетинга. Однако все же есть вероятность того, что ваша информация может быть раскрыта.
Прокси-сервер высокой степени анонимности (High anonymity proxy)
Эти прокси-серверы являются наиболее безопасными, поскольку они не передают ваш IP-адрес и личные данные, а также не идентифицируют себя как прокси при отправке запросов. Также они время от времени меняют свой IP-адрес, который используют для запросов. Именно это позволяет прокси-серверам высокой степени анонимности обеспечивать максимальный уровень конфиденциальности в Интернете.
Такой тип прокси использует браузер TOR. Поскольку IP-адрес время от времени меняется, то серверам крайне сложно отслеживать, какой трафик какому клиенту принадлежит. Если вы хотите, чтобы за вами не могли следить, то это лучший вариант.
Искажающий прокси-сервер (Distorting proxy)
Искажающий прокси-сервер работает аналогично анонимному прокси-серверу. Разница в том, что искажающий прокси-сервер передает IP-адрес, который намеренно является ложным. Он идентифицирует себя как прокси и использует этот ложный IP-адрес в запросах. Это хороший вариант, когда вы хотите сделать так, что вы якобы находитесь в другом месте.
Такой прокси-сервер полезен, когда вы хотите обойти определенные ограничения контента. Это похоже на то, что вы можете выбрать IP-адрес, который вы хотите, чтобы прокси использовал.
Резидентный прокси-сервер (Residential proxy)
Резидентные прокси-серверы – это прокси, которые используют реальные IP-адреса, то есть адреса реальных компьютеров. Это лучший тип прокси, поскольку для серверов они выглядят как обычные клиенты.
Любой из рассмотренных до сих пор типов прокси может быть резидентным. Пока IP-адрес прокси-сервера привязан к физическому устройству, эти типы прокси-серверов, как правило, невозможно обнаружить. Они также решают некоторые проблемы с географией, которые есть у других типов прокси-серверов.
Прокси-сервер центра обработки данных (Data center proxy)
Это своего рода противоположность резидентным прокси. Прокси-серверы центра обработки данных имеют сгенерированные компьютером IP-адреса, которые не привязаны к реальному устройству. Это как прокси в облаке.
Преимущество такого вида прокси заключается в его скорости. Как правило, у поставщиков облачных услуг просто потрясающие Интернет-соединения, которые обеспечат вам такую скорость, которую вы не смогли бы получить как-то иначе. На одном сервере могут размещаться сотни прокси-серверов центра обработки данных, хотя они будут иметь одинаковые IP-адреса.
Публичный прокси-сервер (Public proxy)
Из всех типов прокси-серверов это самые небезопасные и ненадежные прокси. Они могут выйти из строя в любой момент, и многие из них настроены хакерами для кражи данных. Единственная причина, по которой люди все еще используют их, - они бесплатные.
Найти список бесплатных публичных прокси несложно, а вот найти хорошие прокси – задача непростая. Вы никогда не знаете, кто разместил эти прокси-серверы, и отправка любой вашей конфиденциальной информации через них – очень рискованное мероприятие. На публичном прокси может находиться любое количество пользователей в любое время, и никто не контролирует его использование.
Частный прокси-сервер (Private proxy)
Частные прокси-серверы имеют некоторую неоднозначность в отношении того, что они из себя представляют, поскольку они определяются поставщиком услуг. Здесь подразумевается, что ваш прокси-сервер может использоваться только одним клиентом за раз или что ваш прокси-сервер требует аутентификации перед использованием. Это как более надежные версии публичных прокси.
Частный прокси-сервер может быть прозрачным или иметь высокую степень анонимности, подобно некоторым другим, перечисленным выше, таким как резидентный прокси-сервер или прокси-сервер центра обработки данных. Этот тип прокси больше связан с тем, кто может к нему подключиться, чем с тем, как он обрабатывает ваши запросы.
Выделенный прокси-сервер (Dedicated proxy)
Выделенный прокси-сервер похож на определенный тип частного прокси-сервера. Это лишь означает, что прокси не может использоваться несколькими клиентами одновременно, то есть только один клиент может подключаться и отправлять запросы.
Это помогает предотвратить блокировку IP-адреса прокси-сервера различными веб-сайтами и службами. Это один из способов, с помощью которого поставщик прокси-сервера может контролировать, кто имеет доступ к прокси-серверу, чтобы убедиться, что им не злоупотребляют.
Общий прокси-сервер (Shared proxy)
Это один из самых дешевых прокси-серверов, и он работает аналогично общим серверам. Клиенты объединяются и делят стоимость прокси-сервера, и все они могут получить к нему доступ одновременно. Общие прокси-серверы имеют более сложную архитектуру, потому что они одновременно обрабатывают множество запросов.
В зависимости от того, как на общем прокси-сервере распределяются ресурсы, запросы могут выполняться медленнее, чем через ваш собственный IP-адрес. Так как он обрабатывает несколько запросов от нескольких пользователей, конфигурации этих типов прокси-серверов имеют более важное значение, нежели другие.
Ротационный прокси-сервер (Rotating proxy)
Ротационный прокси работает немного иначе, чем остальные. Каждый раз, когда клиент подключается к прокси, для него создается новый IP-адрес. Следовательно, они никогда не используют один и тот же IP-адрес более одного раза.
Каждый раз, когда клиент отправляет запрос, создается новый IP-адрес. Именно так работают прокси-серверы, такие как браузер TOR, чтобы сохранить вашу анонимность. Ротационный прокси-сервер обеспечивает высокий уровень безопасности и конфиденциальности в сочетании с другими типами.
SSL-прокси-сервер (SSL proxy)
Эти прокси-серверы следуют тому же протоколу, что и HTTPS-запросы. «S» в HTTPS означает SSL, что значит, что ваши веб-запросы между клиентом и сервером, к которому вы пытаетесь получить доступ, защищены.
Все это гарантирует, что вы получаете еще более высокий уровень безопасности, так как все ваши запросы через прокси-сервер зашифрованы. Большинство прокси-серверов должны использовать этот протокол по умолчанию, но есть шанс, что вы столкнетесь с теми, которые используют просто HTTP.
Обратный прокси-сервер (Reverse proxy)
Обратные прокси-серверы кардинально отличаются от всех тех, что мы рассматривали ранее. Обратный прокси-сервер скрывает IP-адрес сервера, на который вы пытаетесь отправить запрос. Эти типы прокси-серверов приходят на помощь тогда, когда серверу требуется безопасность и конфиденциальность от клиентов.
Эти прокси отлично подходят, если вам нужно отслеживать доступ к серверу по таким причинам, как предотвращение неконтролируемого доступа клиентов к базе данных. Они также могут помочь снизить трафик в сети, передавая кэшированную информацию вместо того, чтобы каждый раз делать запрос.
Прокси-сервисы
Если вы выполнили быстрый поиск по прокси-сервисам, то уже, вероятно, знаете, что здесь есть из чего выбирать. Не все они одинаково устроены, поэтому важно знать и понимать, какие функции вы хотите получить от своего прокси-сервиса.
Большинство этих сервисов предлагают комбинации различных типов прокси-серверов. Например, вы сможете найти резидентные SSL-прокси-серверы с высокой степенью анонимности в одном сервисе.
Прокси-сервер против VPN
Если вы знакомы с VPN (Virtual Private Network – виртуальная защищенная сеть), то вам может быть интересно, чем отличается прокси-сервер от VPN. Основное отличие заключается в том, что VPN защищает весь ваш сетевой трафик, тогда как прокси-серверы защищают только ваш интернет-трафик.
Есть некоторые вещи, которые VPN защищают, а прокси нет, к ним относятся: передача и прием данных по протоколу FTP, фоновые процессы операционной системы, такие как обновления.
Единственное, что есть общего у прокси и VPN, это то, что они создают впечатление, что ваш интернет-трафик исходит с другого IP-адреса. Это все, что их объединяет. То, как они это воплощают в жизнь, сильно отличается из-за того, для каких целей их используют.
Прокси просто передает ваши интернет-запросы, действуя как посредник. А VPN туннелирует всю вашу сетевую активность до уровня операционной системы. Прокси, как правило, используются одним приложением, таким как браузер или торрент-клиент.
Компании, как правило, используют VPN для того, чтобы сотрудники могли получать доступ к корпоративным ресурсам, не беспокоясь о том, что трафик будет перехвачен или записан Интернет-провайдером. Обычно они размещаются на физическом компьютере на стороне пользователя.
Самое замечательное в VPN то, что они скрывают абсолютно все, что вы делаете. Если бы вдруг ваш Интернет-провайдер получил бы вашу историю использования, то он бы увидел только то, что вы подключены к VPN. Никакой информации о вашем трафике видно не будет. Когда вы подключаетесь к общедоступной сети Wi-Fi, самым безопасным вариантом будет VPN.
Несмотря на то, что у VPN есть множество преимуществ, все же есть веские причины, по которым люди выбирают прокси-серверы. Начнем с того, что VPN, как правило, дороже, чем прокси. Также вам потребуется приличное компьютерное оборудование для запуска VPN. К тому же, соединение VPN обычно медленнее, чем прокси.
В большинстве случаев вам не обязательно требуется тот уровень безопасности, который предлагает VPN. Если вы просто хотите замаскировать свои действия в приложении и при этом сильно не тратиться, то, возможно, стоит подумать о прокси.
Преимущества и риски
Теперь, когда вы знаете о прокси-серверах все, можно поговорить о некоторых преимуществах и рисках, связанных с их использованием. Ниже приведен список:
Преимущества:
Безопасное и конфиденциальное пользование Интернетом
Возможность обойти ограничения, связанные с географическим положением
Лучшая производительность сети
Возможность контролировать доступ клиентов к веб-сайтам
Множество типов, можно выбрать любой под конкретные потребности
Риски:
Ваши запросы могут возвращаться очень медленно
Не все прокси-серверы шифруют ваши запросы, поэтому ваша информация может просочиться
Бесплатные или дешевые прокси-серверы могут быть установлены хакерами или государственными органами
Прокси могут исчезнуть в любой момент
Все ваши запросы и информация всегда проходят через третью сторону, которой может управлять кто угодно
Существует множество других преимуществ и рисков, связанных с использованием любого из типов прокси-серверов. Именно поэтому важно подключаться только к тем прокси, которым вы доверяете. Когда вы подключены к доверенному прокси-серверу, все риски должны быть учтены в конфигурации, чтобы вы ни о чем не беспокоились.
Как настроить простой прокси-сервер
Создание собственного частного прокси-сервера только звучит так сложно, а на деле это не так. Вы можете создать прокси-сервер при помощи компьютера в вашем доме, который будет столь же безопасным, как и большинство прокси-серверов, которые вы можете купить. Нужно лишь немного терпения и пытливости.
На сервере Linux вы можете установить Squid и задать конфигурации для прокси, который вы хотите создать. Вы сможете блокировать определенные веб-сайт или требовать аутентификации, прежде чем клиент сможет подключиться к прокси-серверу.
В Windows и Mac у вас есть возможность создать прокси-сервер с помощью Python и Google App Engine. Вам, конечно, придется заплатить за службу Google App Engine, но она относительно доступная.
Как подключиться к существующему прокси-серверу
Подключение к прокси-серверу, как правило, является простым процессом, если вы знаете информацию о нем, такую как его IP-адрес и номер порта. Прокси обычно быстро настраиваются независимо от того, какую операционную систему вы используете.
В большинстве случаев вы заходите в настройки сети и находите, где можно ввести информацию о прокси-сервере. Затем вы можете подключиться, и может появиться веб-страница, если прокси-сервер включает этап аутентификации. Вот так это выглядит в Windows и Ubuntu.
Настройка прокси-сервера через настройки Windows:
Настройка прокси-сервера через настройки сети Ubuntu:
Заключение
Теперь вы знаете о прокси-серверах все – от того, что они из себя представляют, до того, как создать свой собственный!
Если вам нужно заставить curl игнорировать ошибки сертификата, убедитесь, что вы знаете о последствиях небезопасных соединений и передач SSL.
Вам следует практиковаться в пропуске проверки сертификатов только в целях разработки.
В этом руководстве вы узнаете, как заставить curl игнорировать ошибки сертификата.
Заставить curl игнорировать ошибки SSL
Основной синтаксис игнорирования ошибок сертификата с помощью команды curl:
curl --insecure [URL]
В качестве альтернативы вы можете использовать:
curl -k [URL]
Веб-сайт считается небезопасным, если у него истек срок действия, он неправильно настроен или не имеет сертификата SSL, обеспечивающего безопасное соединение. Когда вы пытаетесь использовать curl для подключения к такому веб-сайту, вывод выдает ошибку.
Примечание. Параметры --insecure (-k) аналогичны команде wget --no-check-certificate, используемой для предотвращения проверки центрами сертификации сертификата сервера.
Например, если вы запустите команду:
curl myawesomewebsite.com
Вывод должен отображать содержимое URL-адреса. Однако, поскольку этот веб-сайт имеет недействительный сертификат SSL, он показывает ошибку, как в примере ниже.
curl: (60) SSL: no alternative certificate subject name matches target host name 'unixtutorial.test'
Это означает, что «сертификат узла не может быть аутентифицирован с помощью известных сертификатов CA».
Чтобы обойти это ограничение, вы можете использовать параметр --insecure (или -k), разрешающий небезопасные соединения с сервером при использовании SSL. Следовательно, вы должны запустить:
curl -k myawesomewebsite.com
Итоги
Прочитав эту статью, вы должны знать, как заставить curl игнорировать ошибки сертификата. Хотя это делается просто путем добавления опции -k, не указывайте curl игнорировать ошибки SSL, если это не требуется для целей разработки.
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через SSH, клонировать клонировать репозиторий с новым кодом, собрать его и запустить через командную строку. Да, такой способ работает, но он малоэффективен. Сегодня мы поговорим об автоматизации процесса разработки и выхода новых версий.
CI и CD – это два сокращения, которые означают Continuous Integration (Непрерывная интеграция) и Continuous Delivery (Непрерывное развертывание).
CI
CI описывает процесс добавления изменений в репозиторий. Ниже схематически представлен простой пример коллективной разработки.
Одновременно может работать целая группа людей, но все изменения передаются в главную ветку master поэтапно. Хотя даже в такой простой схеме возникает несколько вопросов.
Как мы узнаем, что код, который идет в ветку master, компилируется?
Мы хотим, чтобы разработчики писали тесты для кода. Как быть уверенными в том, что тестовое покрытие не уменьшится?
Все сотрудники команды должны форматировать код в соответствие с определенным стилем. Как отследить возможные нарушения?
Конечно же, все это можно проверить вручную. Но такой подход весьма хаотичен. Кроме того, по мере разрастания команды выполнять подобные проверки становится сложнее.
CI используется для автоматизации выше обозначенных пунктов.
Начнем с первого пункта. Как можно проверить, что новые изменения не сломают сборку? Для этого нам потребуется еще один блок в схеме.
Большинство CI-процессов можно описать по следующему алгоритму.
При открытии каждого Pull Request (запроса на включение изменений) и отправке новых изменений, Git-сервер отправляет уведомление CI-серверу.
CI-сервер клонирует репозиторий, проверяет исходную ветку (например bugfix/wrong-sorting) и сливает ее с основной веткой master.
Затем запускается скрипт сборки. Например ./gradlew build.
Если команда возвращает код «0», то сборка прошла успешно. Все остальные значения считаются ошибкой.
CI-сервер отправляет запрос на Git-сервер с результатом сборки.
Если сборка прошла без ошибок, то Pull Request разрешается слить. В противном случае он блокируется.
Данный процесс гарантирует, что код, попадающий в ветку master, не сломает дальнейшие сборки.
Проверка тестового покрытия
Давайте немного усложним задачу. Предположим, нам захотелось установить минимальный охват тестового покрытия. Это означает, что в любой момент времени покрытие ветки master должно быть не менее 50%. Плагин Jacoco идеально справляется с этой задачей. Вы просто настраиваете его так, чтобы при охвате тестового покрытия ниже допустимого, сборка уходила в ошибку.
Реализовать такой подход проще некуда. Но есть небольшая оговорка. Этот метод работает только при условии, что плагин настраивался на старте проекта.
Представим ситуацию: вы работаете над проектом, которому уже 5 лет. С момента первого коммита никто не проверял тестовое покрытие. Разработчики добавляли тесты в случайном порядке и без какой-либо организации. Но вот однажды вы решаете увеличить количество тестов. Вы настраиваете плагин Jacoco на минимальную планку в 60%. Спустя какое-то время разработчик открывает новый Pull Request. Затем разработчики вдруг понимают, что покрытие – всего лишь 30%. Так что для успешного закрытия задачи нужно покрыть не менее 30% кода продукта. Как вы можете догадаться, для проекта 5-летней давности – это практически неразрешимая проблема.
Но что, если будут проверяться только будущие изменения в коде, а не весь продукт? Если в Pull Request разработчик изменит 200 строк, то нужно будет охватить не менее 120 из них (при тестовом покрытии в 60%). Тогда не придется проходить по множеству модулей, которые не относятся к задаче. В принципе, проблема решаема. Но как применить все это к проекту? К счастью, есть решение.
Отчет Jacoco отправляется на сервер тестового покрытия.
Одно из самых популярных решений – SonarCloud.
Сервер хранит статистику по предыдущим вычислениям. Это очень удобно: вычислять тестовое покрытие не только всего кода, но и будущих изменений. Затем результат анализа отправляется на CI-сервер, который перенаправляет его на Git-сервер.
Такая рабочая модель позволяет применять культуру обязательного тестирования на любой стадии развития продукта, поскольку проверяется лишь часть изменений.
Если говорить о стиле оформления кода, то отличий практически нет. Можете попробовать плагин Checkstyle. Он автоматически отклоняет сборку, которая нарушает любое из заявленных требований. Например, в коде есть неиспользованный импорт. Кроме того, вы можете присмотреться к облачным сервисам, которые выполняют анализ кода и визуально отображают результаты в виде графиков (SonarCloud это тоже умеет).
CD
CD описывает процесс автоматического развертывания новой версии продукта.
Давайте еще немного подкорректируем схему CI. Вот так конвейерный процесс CI/CD мог бы выглядеть в реальном проекте.
Первое отличие – теперь CI-сервер называется CI/CD-сервером. Дело в том, что зачастую оба процесса (CI и CD) выполняются одним и тем же диспетчером задач. Так что мы будем рассматривать именно этот случай.
Но так бывает не всегда. Например, задачи по интеграции могут делегироваться на GitLab CI, а задачи по доставке – отдаваться в Jenkins.
Правая часть схемы изображает CI. Мы обсудили ее выше. Слева показана CD. Задача по CD создает проект (или повторно использует артефакты, полученные на стадии CI) и развертывает его на конечном сервере.
Стоит отметить, что сервер в нашем случае – это понятие абстрактное. Например, развертывание может выполняться в кластер Kubernetes. Так что самих серверов может быть несколько.
Обычно после стадии развертывания на почту приходят сообщения о выполнении. Например, CD-сервер может уведомлять подписчиков об успешном развертывании/ошибках.
В любом случае, возникает важный вопрос. В какой момент мы должны запускать задачи по CD? Триггеры могут быть разными.
Развертывание после каждого слияния Pull Request.
Развертывание по расписанию.
Развертывание после каждого слияния Pull Request с определенной веткой.
Сочетание нескольких вариантов.
В первом пункте процесс выстроен так, что задачи по CI и CD всегда выполняются последовательно. Данный подход весьма популярен при разработке программ с исходным кодом. Библиотека Semantic Release помогает настроить проект для прозрачной интеграции данной модели.
Важно помнить о трактовке понятия deploy (развертывание). Это не всегда «что-то где-то запустить». Например, при разработке библиотеки, нет никакого запуска. В данном случае процесс развертывания означает выпуск новой версии библиотеки.
Второй пункт не зависит от процесса CI, ведь проект развертывается по определенному расписанию. Например, ежедневно в 01:00.
Третий пункт аналогичен первому, но с небольшими отличиями. Предположим, в репозитории у нас есть 2 основные ветки: develop и master. В develop содержатся самые последние изменения, а в master – только релизы версий. Если мы хотим развертывать только ветку master, то не нужно вызывать CD-задачу по слиянию в develop.
Последний пункт – это сочетание подходов. Например, ветку develop можно развертывать по расписанию в среду разработки. А ветку master – в реальную среду по каждому слиянию Pull Request.
Инструменты
На рынке доступно множество решений по автоматизации процессов CI/CD. Ниже представлено несколько продуктов.
Jenkins. Один из самых востребованных инструментов CI/CD в мире. Свою популярность он заслужил, благодаря политике открытого кода (open-source). То есть вам не нужно ни за что платить. В Jenkins вы можете императивно описывать конвейеры сборки с помощью Groovy. С одной стороны это достаточно гибкое решение, но с другой – требует более высокого уровня квалификации.
GitHub Actions. Этот инструмент для CI/CD доступен для GitHub и GitHub Enterprise. В отличие от Jenkins, GitHub Actions предлагает декларативные сценарии сборки с YAML-конфигурацией. Кроме того, в данном решении доступна интеграция с различными системами обеспечения качества (например SonarCube). Таким образом, сборку можно описать в нескольких текстовых строках.
GitLab CI. Во многом похож на GitHub Actions, но со своими особенностями. Например, GitLab CI может указывать на определенные тесты, вызывающие ошибку в сборке.
Travis CI. Облачный CI/CD-сервис. Предлагает множество возможностей, не требующих сложных настроек. Например, шифрование данных, которые следует скрыть в публичном репозитории. Есть и приятный бонус в том, что Travis CI можно совершенно бесплатно использовать в публичных open-source проектах на GitHub, GitLab и BitBucket.