One place for hosting & domains

      Введение

      Введение в работу с библиотекой Requests в Python


      Введение

      Многие веб-приложения используют API для подключения к различным сторонним сервисам. Используя API, вы можете получать доступ к таким данным как информация о погоде, результаты спортивных состязаний, рейтинги фильмов, твиты, результаты поиска в поисковых системах и изображения. Также вы можете использовать API для добавления функционала в ваше приложение, например платежей, планирования, отправки сообщений электронной почты, переводов, карт и передачи файлов. Самостоятельное создание таких инструментов может занять очень много времени, а API позволяют за считанные минуты подключиться к источнику и получить доступ к его функциям и данным.

      Из этой статьи вы узнаете о библиотеке Python Requests, позволяющей отправлять запросы HTTP в Python.

      Поскольку при использовании API отправляются запросы HTTP и получаются ответы, библиотека Requests открывает возможность использования API в Python. Мы продемонстрируем использование API для языкового перевода, чтобы вы увидели, как это работает.

      Краткий обзор запросов HTTP

      Запросы HTTP лежат в основе всемирной сети. Каждый раз, когда вы открываете веб-страницу, ваш браузер направляет множество запросов на сервер этой веб-страницы. Сервер отвечает на них, пересылая все необходимые данные для вывода страницы, и ваш браузер отображает страницу, чтобы вы могли увидеть ее.

      В целом этот процесс выглядит так: клиент (например браузер или скрипт Python, использующий библиотеку Requests) отправляет данные на URL, а сервер с этим URL считывает данные, решает, что с ними делать, и отправляет клиенту ответ. После этого клиент может решить, что делать с полученными в ответе данными.

      В составе запроса клиент отправляет данные по методу запроса. Наиболее распространенными методами запроса являются GET, POST и PUT. Запросы GET обычно предназначены только для чтения данных без их изменения, а запросы POST и PUT обычно предназначаются для изменения данных на сервере. Например, Stripe API позволяет использовать запросы POST для тарификации, чтобы пользователь мог купить что-нибудь в вашем приложении.

      Примечание. В этой статье рассказывается о запросах GET, поскольку мы не собираемся изменять никакие данные на сервере.

      При отправке запроса из скрипта Python или веб-приложения вы как разработчик решаете, что отправлять в каждом запросе и что делать с полученными ответами. Для начала отправим запрос на Scotch.io и используем API для перевода.

      Установка Python Requests

      Прежде чем мы сможем что-либо сделать, нам нужно установить библиотеку. Так что для начала мы установим библиотеку Requests с помощью pip. Если вы еще не создали виртуальную среду, стоит сделать это сейчас.

      Наш первый запрос

      Для начала мы используем библиотеку Requests для отправки запроса на сайт Scotch.io. Создайте файл с именем script.py и добавьте в него следующий код. В этой статье мы рассматриваем небольшое количество кода, поэтому если что-то изменится, вы можете просто обновить существующий код вместо добавления новых строк.

      script.py

      import requests
      
      res = requests.get('https://scotch.io')
      
      print(res)
      

      Этот код просто отправляет запрос GET на сайт Scotch.io. Это такой же тип запроса, какой используется вашим браузером для просмотра этой страницы, и единственное отличие заключается в том, что библиотека Requests не может выполнить рендеринг кода HTML, и поэтому вы получите просто код HTML и другую информацию, содержащуюся в ответе.

      Здесь мы используем функцию .get(), однако Requests также позволяет использовать при отправке запросов и другие функции, в том числе .post() и .put().

      Для отправки запроса нужно запустить файл script.py.

      Вот что вы получите в результате: запуск скрипта с результатами `Response 200`.

      Коды состояния

      Прежде всего мы проверим код состояния. Коды HTTP находятся в диапазоне от 1XX до 5XX. Наверняка вы уже знакомы с кодами состояния 200, 404 и 500.

      Далее мы приведем краткий обзор значений кодов состояния:

      • 1XX — информация
      • 2XX — успешно
      • 3XX — перенаправление
      • 4XX — ошибка клиента (ошибка на вашей стороне)
      • 5XX — ошибка сервера (ошибка на их стороне)

      Обычно при выполнении наших собственных запросов мы хотим получить коды состояния в диапазоне 200.

      Библиотека Requests понимает, что коды состояния 4XX и 5XX сигнализируют об ошибках, и поэтому при возврате этих кодов состояния объекту ответа на запрос присваивается значение False.

      Проверив истинность ответа, вы можете убедиться, что запрос успешно обработан. Например:

      script.py

      if res:
          print('Response OK')
      else:
          print('Response Failed')
      

      Результат Response 200 с последующим сообщением Response OK

      Сообщение Response Failed появится только при возврате кода состояния 400 или 500. Попробуйте заменить URL на несуществующий, чтобы увидеть ошибку ответа 404.

      Чтобы посмотреть код состояния, добавьте следующую строку:

      script.py

      print(res.status_code)
      

      Так вы увидите код состояния и сможете сами его проверить.

      Ошибка результата с кодом 404

      Заголовки

      Также в ответе вы можете получить заголовки. Вы можете посмотреть их, используя словарь headers для объекта response.

      script.py

      print(res.headers)
      

      результаты с печатью заголовка в стандартном выводе

      Заголовки отправляются вместе с запросом и возвращаются с ответом. Заголовки используются для того, чтобы клиент и сервер понимали, как интерпретировать данные, отправляемые и получаемые в запросе и ответе.

      Мы увидим в ответе несколько заголовков. Обычно информация из заголовков не требуется, однако если она вам нужна, вы можете ее получить.

      Обычно требуется заголовок content type, поскольку он показывает формат данных, например HTML, JSON, PDF, обычный текст и т. д. Однако заголовок content type обрабатывается библиотекой Requests, и вы имеете доступ ко всем возвращаемым данным.

      Текст ответа

      Если мы посмотрим на файл res.text (это работает для текстовых данных, таких как просматриваемая нами страница HTML), мы увидим весь код HTML, требуемый для построения домашней страницы Scotch. Рендеринг выполняться не будет, но мы увидим, что он принадлежит Scotch. Если вы сохраните этот код в файл и откроете его, вы увидите что-то похожее на сайт Scotch. В реальных условиях для загрузки на одну веб-страницу изображений, скриптов, таблиц стилей и т. д. отправляется несколько запросов, так что если вы сохраните в файл только код HTML и откроете его в браузере, результат не будет похож на страницу Scotch.io, поскольку для получения данных HTML был отправлен только один запрос.

      script.py

      print(res.text)
      

      Распечатанные данные HTML в командной строке

      Использование Translate API

      Теперь перейдем к чему-то более интересному. Мы используем API Яндекс.Перевод (Yandex Translate API) для выполнения запроса на перевод текста на другой язык.

      Чтобы использовать API, нужно предварительно войти в систему. После входа в систему перейдите к Translate API и создайте ключ API. Когда у вас будет ключ API, добавьте его в свой файл в качестве константы. Далее приведена ссылка, с помощью которой вы можете сделать все перечисленное: https://tech.yandex.com/translate/

      script.py

      API_KEY = 'your yandex api key'
      

      Ключ API нужен, чтобы Яндекс мог проводить аутентификацию каждый раз, когда мы хотим использовать его API. Ключ API представляет собой облегченную форму аутентификации, поскольку он добавляется в конце URL запроса при отправке.

      Чтобы узнать, какой URL нам нужно отправить для использования API, посмотрим документацию Яндекса.

      Там мы найдем всю информацию, необходимую для использования их Translate API для перевода текста.

      Синтаксис запроса на использование API

      Если вы видите URL с символами амперсанда (&), знаками вопроса (?) или знаками равенства (=), вы можете быть уверены, что это URL запроса GET. Эти символы задают сопутствующие параметры для URL.

      Обычно все, что размещено в квадратных скобках ([]), будет необязательным. В данном случае для запроса необязательны формат, опции и обратная связь, но обязательны параметры key, text и lang.

      Добавим код для отправки на этот URL. Замените первый созданный нами запрос на следующий:

      script.py

      url = 'https://translate.yandex.net/api/v1.5/tr.json/translate'
      res = requests.get(url)
      

      Существует два способа добавления параметров. Мы можем прямо добавить параметры в конец URL, или библиотека Requests может сделать это за нас. Для последнего нам потребуется создать словарь параметров. Нам нужно указать три элемента: ключ, текст и язык. Создадим словарь, используя ключ API, текст Hello и язык en-es, т. к. нам требуется перевод с английского на испанский.

      Другие коды языков можно посмотреть здесь. Нам нужен столбец 639-1.

      Мы создаем словарь параметров, используя функцию dict(), и передаем ключи и значения, которые хотим использовать в нашем словаре.

      script.py

      params = dict(key=API_KEY, text='Hello', lang='en-es')
      

      Теперь возьмем словарь параметров и передадим его функции .get().

      script.py

      res = requests.get(url, params=params)
      

      Когда мы передаем параметры таким образом, Requests автоматически добавляет параметры в URL за нас.

      Теперь добавим команду печати текста ответа и посмотрим, что мы получим в результате.

      script.py

      print(res.text)
      

      вывод словаря с введенными значениями

      Мы видим три вещи. Мы видим код состояния, который совпадает с кодом состояния ответа, мы видим заданный нами язык и мы видим переведенный текст внутри списка. Итак, мы должны увидеть переведенный текст Hola.

      Повторите эту процедуру с кодом языка en-fr, и вы получите ответ Bonjour.

      script.py

      params = dict(key=API_KEY, text='Hello', lang='en-fr')
      

      Переведенный текст на французском

      Посмотрим заголовки полученного ответа.

      script.py

      print(res.headers)
      

      Распечатанные заголовки на экране результатов

      Разумеется, заголовки должны быть другими, поскольку мы взаимодействуем с другим сервером, но в данном случае мы видим тип контента application/json вместо text/html. Это означает, что эти данные могут быть интерпретированы в формате JSON.

      Если ответ имеет тип контента application/json, библиотека Requests может конвертировать его в словарь и список, чтобы нам было удобнее просматривать данные.

      Для обработки данных в формате JSON мы используем метод .json() на объекте response.

      Если вы распечатаете его, вы увидите те же данные, но в немного другом формате.

      script.py

      json = res.json()
      print(json)
      

      Причина отличия заключается в том, что это уже не обычный текст, который мы получаем из файла res.text. В данном случае это печатная версия словаря.

      Допустим, нам нужно получить доступ к тексту. Поскольку сейчас это словарь, мы можем использовать ключ текста.

      script.py

      print(json['text'])
      

      Теперь мы видим данные только для этого одного ключа. В данном случае мы видим список из одного элемента, так что если мы захотим напрямую получить текст в списке, мы можем использовать указатель для доступа к нему.

      script.py

      print(json['text'][0])
      

      Bonjour без квадратных скобок

      Теперь мы видим только переведенное слово.

      Разумеется, если мы изменим параметры, мы получим другие результаты. Изменим переводимый текст с Hello на Goodbye, изменим язык перевода на испанский и снова отправим запрос.

      script.py

      params = dict(key=API_KEY, text='Goodbye', lang='en-es')
      

      Выводится текст Adios Попробуйте перевести более длинный текст на другие языки и посмотрите, какие ответы будет вам присылать API.

      Примеры ошибок Translate API

      В заключение рассмотрим пример ошибки. Иногда что-то не работает, и нужно знать, что делать в подобных случаях.

      Попробуйте изменить ключ API, удалив один символ. Теперь ваш ключ API будет недействителен. Попробуйте отправить запрос.

      Если вы посмотрите код состояния, вы увидите следующее:

      script.py

      print(res.status_code)
      

      Ошибка 403 При использовании API нужно проверять, был ли запрос успешно выполнен, чтобы вы могли обрабатывать ошибки в соответствии с требованиями вашего приложения.

      Заключение

      Мы узнали следующее:

      • Принципы работы запросов HTTP
      • Различные коды состояния, которые могут присутствовать в ответе
      • Как отправлять запросы и получать ответы с помощью библиотеки Python Requests
      • Как использовать API языкового перевода для перевода текста
      • Как конвертировать ответы в формате application/JSON в словари

      Если вы хотите узнать больше, посмотрите в этом списке различные доступные API и попробуйте использовать их с библиотекой Python Requests.



      Source link

      Введение в лучшие практики CI/CD


      Введение

      Методика непрерывной интеграции, доставки и развертывания (CI/CD) — неотъемлемая часть современного процесса разработки, призванная снизить количество ошибок во время интеграции и развертывания и повысить скорость реализации проектов. CI/CD — это одновременно философия и набор практик, которые часто усиливваются высоконадежными инструментами, обеспечивающими автоматическое тестирование на каждом шаге конвейера программного обеспечения. Добавляя их в свою практику, вы можете сократить затраты времени на интеграцию изменений в новом выпуске и тщательно тестировать каждое изменение перед переносом в производственную среду.

      CI/CD имеет множество потенциальных преимуществ, однако для успешной реализации часто требуется тщательный анализ. Принятие точного решения относительно использования инструментов и необходимых изменений в среде может оказаться непростой задачей, если не прибегать к методу проб и ошибок. Однако хотя разные виды реализации будут различаться, лучшие практики помогут вам избежать распространенных проблем и быстрее совершенствовать свою среду.

      В этом обучающем модуле содержатся базовые указания по внедрению и поддержке системы CI/CD для оптимального соответствия потребностям вашей организации. Мы расскажем о ряде практик, которые помогут повысить эффективность вашей службы CI/CD. Вы можете прочитать этот материал целиком или сразу перейти к интересующим вас разделах.

      Поддержание высокой скорости конвейеров

      Конвейеры CI/CD помогают внедрять изменения в рамках автоматизированных циклов тестирования, в том числе в тестовых и производственных средах Чем больше процедур охватывают ваши конвейеры тестирования, тем надежнее гарантия отсутствия побочных эффектов изменений при развертывании в производственной среде. Однако поскольку данную процедуру следует применять для всех изменений, быстрота и надежность конвейера очень важны для сохранения скорости разработки.

      Возможно баланс между этими двумя требованиями не так просто достичь. Вы можете предпринять ряд простых шагов для повышения скорости работы, включая масштабирование инфраструктуры CI/CD и оптимизацию тестирования. Однако с течением времени у вас может возникнуть необходимость принимать критически важные решения касательно относительной ценности разных тестов и этапа или порядка их выполнения. Иногда для сохранения требуемой скорости процессов лучше всего удалить из набора тестов некоторые компоненты, имеющие наименьшую ценность или дающие плохо интерпретируемые результаты.

      При принятии этих важных решений следует понимать и документировать принимаемые решения. Проконсультируйтесь с членами команды и заинтересованными лицами, чтобы понять представление команды относительно задач комплекса тестирования, а также определить наиболее важные области.

      Изоляция и защита среды CI/CD

      С точки зрения операционной безопасности система CI/CD отражает наиболее важную инфраструктуру для защиты. Поскольку система CI/CD имеет полный доступ к вашей базе кода и учетным данным для развертывания в различных средах, очень важно обеспечить защиту внутренних данных и обеспечить целостность вашего сайта или продукта. В связи с высокой важностью системы CI/CD как объекта атаки, очень важно изолировать и защитить ее как можно лучше.

      Системы CI/CD следует развертывать во внутренних защищенных сетях без возможности внешнего доступа. Рекомендуется настроить VPN и другие технологии контроля доступа к сети, чтобы ваша система была доступна только прошедшим аутентификацию операторам. В зависимости от сложности топологии вашей сети, вашей системе CI/CD может потребоваться доступ к разным сетям для развертывания кода в разнообразных средах. Если сети не будут надлежащим образом защищены или изолированы, злоумышленники с доступом к одной среде могут использовать этот доступ для эксплуатации уязвимостей внутренних сетей с целью получения доступа к другим серверам через слабые места серверов CI/CD.

      Требуемые стратегии изоляции и защиты зависят от топологии сети, инфраструктуры и требований к управлению и разработке. Очень важно помнить, что ваши системы CI/CD представляют собой очень важные цели для злоумышленников, поскольку они часто имеют высокий уровень доступа к другим критически важным системам. Защита внешнего доступа к серверам и жесткий контроль внутреннего доступа помогут снизить риск взлома вашей системы CI/CD.

      Прекращение конвейера CI/CD в единственный способ развертывания в производственной среде

      Инструменты для внедрения передовых практик тестирования и развертывания также помогают системам CI/CD оптимизировать процесс разработки и повысить качество кода. Для распространения кода через конвейеры CI/CD необходимо сделать так, чтобы каждое изменение соответствовало кодифицированным стандартам и процедурам вашей организации. Любые неисправности конвейера CI/CD сразу же становятся заметными, и при их возникновении процесс разработки новых версий останавливается на последующих этапах цикла. Такой механизм защищает важные среды от ненадежного кода.

      Для использования этих преимуществ требуется внедрить надлежащую производственную дисциплину, чтобы все изменения рабочей среды проходили через ваш конвейер. Конвейер CI/CD должен быть единственным механизмом поступления кода в производственную среду. Это может делаться автоматически в конце успешного тестирования с применением практик непрерывной разработки, а также посредством ручного распространения протестированных изменений, одобренных и опубликованных через систему CI/CD.

      Очень часто команды разработчиков используют конвейеры для развертывания, но при этом допускают исключения при возникновении проблем и необходимости их срочного решения. Хотя простои и другие проблемы необходимо устранять как можно скорее, при этом очень важно понимать, что система CI/CD обеспечивает отсутствие ошибок, новых неисправностей и других побочных эффектов при внедрении изменений. Развертывание исправлений через конвейер (или просто использование системы CI/CD для отката) также предотвращает удаление напрямую установленных исправлений при развертывании следующих версий. Конвейер защищает целостность как плановых обновлений, так и экстренных обновлений, призванных устранить текущие проблемы. Такое использование системы CI/CD также дает еще одну причину обеспечить максимальное быстродействие конвейера.

      Сохранение соответствия с производственной средой по мере возможности

      Конвейеры CI/CD используются для развертывания изменений через тестовые комплекты и среды развертывания. Изменения, проходящие проверку на соответствие требованиям на одном этапе, автоматически развертываются или помещаются в очередь ручного развертывания для сред с более высокими требованиями. Ранние этапы тестирования призваны подтвердить ценность тестирования и внедрения изменений на уровнях, находящихся ближе к производственной среде.

      На более поздних этапах воспроизведение производственной среды в тестовых средах обеспечивает более точное соответствие тестов реальной реакции производственной среды на изменения. При значительных отличиях между тестовыми и производственными средами существует вероятность возникновения при развертывании проблем, которые не наблюдались при тестировании. Чем больше будет заметно отличий между рабочей средой и тестовой средой, тем меньше уверенности в стабильной работе приложений дают тесты.

      Небольшие отличия между тестовыми и производственными средами закономерны, но их необходимо контролировать и хорошо понимать. Некоторые организации используют схему развертывания «синий-зеленый» для переключения производственного трафика межжду двумя практически идентичными средами, которые по очереди выполняют функции рабочей и тестовой среды. Менее экстремальные стратегии предусматривают использование в тестовой среде той же конфигурации, что и в рабочей среде. но в уменьшенном масштабе. Конечные точки сети и другие подобные элементы разных сред могут отличаться, однако параметризация такого типа переменных данных поможет обеспечить единообразие кода и четкое определение отличий разных сред.

      Выполните только одну сборку и разверните результаты через конвейер

      Основная цель конвейера CI/CD — обеспечить уверенность в изменениях и минимизировать вероятность непредвиденного негативного воздействия. Мы обсудили важность поддержания соответствия сред, однако один компонент такого соответствия заслуживает особого внимания. Если для вашего программного обеспечения требуется этап сборки, упаковки или объединения в комплект, этот этап должен выполняться только один раз, и его результат должен многократно использоваться в масштабах всего конвейера.

      Это правильно поможет предотвратить проблемы, возникающие при многократной компиляции или упаковке программного обеспечения, в результате чего могут возникать небольшие несоответствия или ошибки. Отдельная сборка программного обеспечения на каждом новом этапе означает, что в предыдущем тестировании использовалось не то же самое программное обеспечение, что делает результаты недействительными.

      Для предотвращения этой проблемы в системы CI должен быть включен процесс сборки на первом этапе конвейера, предусматривающий создание и упаковку программного обеспечения в чистой среде. Полученную сборку с присвоенным номером версии следует выгрузить в хранилище артефактов, откуда она будет извлекаться на следующих частях конвейера. Это гарантирует, что на разных участках системы будет использоваться одна и та же сборка.

      Самые быстрые тесты следует проводить заранее

      Хотя быстрая работа конвейера в целом очень важна, некоторые части комплекса тестирования будут неизбежно выполняться быстрее других. Поскольку система CI/CD обрабатывает все изменения в системе, очень важно как можно раньше обнаруживать любые неполадки, чтобы минимизировать выделение ресурсов на проблемные варианты сборки. Для этого желательно в приоритетном порядке выполнять самые быстрые тесты. Сложные и длительные тесты лучше отложить до тех пор, пока вы не проверите сборку с помощью небольших и быстрых тестов.

      Такая стратегия дает ряд преимуществ, помогающих оптимизировать процесс CI/CD. Она помогает лучше понять влияние отдельных тестов на производительность, быстро выполнять основную часть тестов и раньше выявлять неполадки, что позволит отменить проблемные изменения или внести исправления, до того, как неполадки скажутся на работе.

      Приоритетное тестирование подразумевает первоочередное выполнение тестов проектного компонента, поскольку эти тесты обычно быстрые, изолированные и ориентированы на конкретные элементы. Тесты интеграции идут следующими по скорости и сложности, затем идут системные тесты, а на последнем этапе идут приемочные испытания, в которых обычно принимают участие операторы.

      Минимизируйте ветвление в системе управления версиями

      Один из главных принципов CI/CD — быстро и часто интегрировать любые изменения в главное общее хранилище. Это помогает избежать дорогостоящих проблем с интеграцией на поздних этапах, когда разные разработчики записывают большие, разнородные и даже конфликтующие друг с другом пакеты изменений в главное хранилище непосредственно перед выпуском. Обычно системы CI/CD настраиваются для мониторинга и тестирования изменений, влияющих на одно или несколько ответвлений проекта.

      Чтобы использовать все преимущества CI в полной мере. лучше всего ограничить количество и состав ответвлений в вашем хранилище. В большинстве вариантов реализации предполагается, что разработчики будут записывать изменения непосредственно в главное хранилище или хотя бы раз в день синхронизировать его с локальными ответвлениями.

      Ответвления, которые не отслеживаются системой CI/CD, содержат непроверенный код, и должны рассматриваться как риск для успеха и скорости выполнения проекта. Минимизация ответвлений для быстрой интеграции кода разных разработчиков помогает использовать сильные стороны системы и не дает разработчикам аннулировать ее преимущества.

      Локальное выполнение тестов до отправки в конвейер CI/CD

      Продолжая вышесказанное, также разработчикам рекомендуется выполнять как можно больше тестов на локальном уровне, прежде чем записывать изменения кода в общее хранилище. Это позволяет обнаруживать определенные проблемные изменения до того, как они начнут мешать работе других членов команды. Хотя в локальной среде разработки вряд ли можно будет выполнить полный набор тестов, такой же как в производственной среде, этот дополнительный шаг дает разработчикам уверенность, что их код соответствует требованиям базовых тестов, и его стоит интегрировать в основную базу кода.

      Чтобы разработчики могли эффективно выполнять тестирование самостоятельно, набор тестов должен запускаться с помощью одной команды из любой среды. Та же самая команда, которую будут использовать разработчики на своих локальных компьютерах, должна использоваться системой CI/CD для запуска тестов кода в хранилище. Обычно для координации используется скрипт оболочки или файл makefile, которые автоматизируют инструменты тестирования, помогая получать воспроизводимые и прогнозируемые результаты.

      Выполнение тестов в абстрагированных средах, если это возможно

      Чтобы все тесты на разных этапах выполнялись одинаково, имеет смысл использовать чистые абстрагированные среды тестирования, если это возможно. Обычно это означает, что тесты выполняются в контейнеров для абстрагирования разницы между системами хоста и предоставления стандартного API для объединения компонентов в различных масштабах. Поскольку контейнеры работают с минимальным состоянием, побочные эффекты тестирования не воспроизводятся при последующих запусках набора тестов, что могло бы исказить результаты.

      Еще одно преимущество контейнерных сред тестирования — удобство переноса и воспроизведения инфраструктуры тестирования. С помощью контейнеров разработчики могут легко воспроизвести конфигурацию на следующих этапах конвейера без ручной настройки и обслуживания инфраструктуры и без необходимости жертвовать удобством среды. Поскольку контейнеры можно легко развертывать и уничтожать, пользователям реже придется идти на компромиссы в отношении точности среды тестирования при запуске локальных тестов. Использование контейнерных блокировок в целом помогает минимизировать различия между разными этапами конвейера.

      Заключение

      Хотя разные виды реализации CI/CD могут различаться, следование некоторым из этих базовых принципов поможет избежать распространенных проблем и оптимизировать практики тестирования и разработки. Непрерывная интеграция и сочетание процессов, инструментов и правил работы помогут сделать изменения в разработке более успешными и эффективными.

      Чтобы узнать больше об общих практиках CI/CD и о настройке различных служб CI/CD, читайте другие статьи с пометкой CI/CD.



      Source link

      Введение в диспетчер пакетов Helm для Kubernetes


      Введение

      Развертывание приложений в мощной и популярной системе организации контейнеров Kubernetes может представлять собой сложную задачу. Для настройки одного приложения может потребоваться создание нескольких независимых ресурсов Kubernetes, в том числе подов, служб, развертываний и наборов копий, и для каждого из этих ресурсов требуется детализированный файл манифеста YAML.

      Helm — это диспетчер пакетов для Kubernetes, упрощающий для разработчиков и операторов упаковку, настройку и развертывание приложений и служб в кластерах Kubernetes.

      Helm уже является официальным проектом Kubernetes и поддерживается некоммерческим фондом Cloud Native Computing Foundation, который поддерживает проекты с открытым исходным кодом, связанные с экосистемой Kubernetes.

      В этой статье мы приведем обзор Helm и различных абстракций, которые он использует для развертывания приложений в Kubernetes. Если вы еще мало знакомы Kubernetes, прочитайте статью «Введение в Kubernetes», чтобы ознакомиться с базовыми концепциями.

      Обзор Helm

      Практически у каждого языка программирования и каждой операционной системы имеется собственный диспетчер пакетов, служащий для установки и обслуживания программного обеспечения. Helm имеет те же базовые функции, что и другие знакомые вам диспетчеры пакетов, такие как apt в Debian или pip в Python.

      Helm может выполнять следующие задачи:

      • Установка программного обеспечения.
      • Автоматическая установка зависимостей программного обеспечения.
      • Обновление программного обеспечения.
      • Настройка развертывания программного обеспечения.
      • Доставка пакетов программного обеспечения из репозиториев.

      Helm реализует эти возможности с помощью следующих компонентов:

      • Инструмент командной строки helm, обеспечивающий пользовательский интерфейс для всех функций Helm.
      • Сопутствующий серверный компонент tiller, который работает на кластере Kubernetes, прослушивает команды helm и обрабатывает конфигурации и развертывание версий программного обеспечения в кластере.
      • Формат пакетов Helm, называемый charts.
      • Официальный курируемый репозиторий charts с готовыми пакетами charts для популярных проектов программного обеспечения с открытым исходным кодом.

      Далее мы более подробно расскажем о формате charts.

      Формат Charts

      Пакеты Helm имеют формат charts и состоят из нескольких файлов конфигурации YAML и шаблонов, преобразуемых в файлы манифеста Kubernetes. Базовая структура каталогов пакета charts выглядит следующим образом:

      Example chart directory

      package-name/
        charts/
        templates/
        Chart.yaml
        LICENSE
        README.md
        requirements.yaml
        values.yaml
      

      Эти каталоги и файлы имеют следующие функции:

      • charts/: в этот каталог можно помещать управляемые вручную зависимости пакета, хотя обычно лучше использовать файл requirements.yaml для динамической привязки зависимостей.
      • templates/: этот каталог содержит файлы шаблона, которые комбинируются со значениями конфигурации (из файла values.yaml и командной строки) и записываются в манифесты Kubernetes. Для шаблонов используется формат шаблонов языка программирования Go.
      • Chart.yaml: файл YAML с метаданными о пакете, включая название и версию пакета, информацию об обслуживании, актуальный сайт и ключевые слова для поиска.
      • LICENSE: лицензия пакета в текстовом формате.
      • README.md: файл readme с информацией для пользователей пакета.
      • requirements.yaml: файл YAML с перечислением зависимостей пакета.
      • values.yaml: файл YAML со значениями конфигурации пакета по умолчанию.

      Команда helm может использоваться для установки пакета из локального каталога или из упакованной версии .tar.gz этой структуры каталогов. Упакованные пакеты также можно автоматически загружать и устанавливать из репозиториев пакетов или repos.

      Далее мы рассмотрим репозитории пакетов.

      Репозитории пакетов

      Репозиторий пакетов Helm — это простой сайт HTTP, обслуживающий упакованные пакеты в файлах index.yaml и .tar.gz. Команда helm имеет две субкоманды для упаковки пакетов и создания требуемого файла index.yaml. Эти файлы может обслуживать любой веб-сервер, служба хранения объектов или хост статических сайтов, например GitHub Pages.

      В Helm настроен репозиторий пакетов по умолчанию с именем stable. Этот репозиторий указывает на объект Google Storage по адресу https://kubernetes-charts.storage.googleapis.com. Источник репозитория stable можно найти в репозитории Git helm/charts на GitHub.

      Альтернативные репозитории можно добавлять с помощью команды helm repo add. Ниже представлены некоторые популярные альтернативные репозитории:

      Если вы устанавливаете локально разработанный пакет или пакет из репозитория, вам нужно настроить его для своей конкретной системы. Теперь мы перейдем к конфигурациям.

      Конфигурация пакетов

      Значения конфигурации пакета по умолчанию обычно содержатся в файле values.yaml этого пакета. Некоторые приложения можно полностью развернуть со значениями по умолчанию, однако в большинстве случаев требуется изменить некоторые элементы конфигурации.

      Значения, открываемые для настройки через конфигурацию, определяются автором пакета. Некоторые из них используются для настройки примитивов Kubernetes, а некоторые передаются в базовый контейнер для настройки самого приложения.

      Далее приведен сниппет с примерами значений:

      values.yaml

      service:
        type: ClusterIP
        port: 3306
      

      Это варианты настройки ресурса службы Kubernetes. Вы можете использовать команду helm inspect values chart-name для очистки всех доступных значений конфигурации пакета.

      Эти значения можно переопределить в собственном файле YAML, используемом при запуске команды helm install, или через отдельные параметры командной строки с флагом --set. Нужно указать только те значения, для которых вы хотите изменить параметры по умолчанию.

      Пакет Helm, развернутый в определенной конфигурации, назыается релизом. Далее мы поговорим о релизах.

      Релизы

      Во время установки пакета Helm объединяет шаблоны пакета с заданной пользователем конфигурацией и значеними по умолчанию из файла value.yaml. Для этих пакетов выполняется рендеринг в манифестах Kubernetes, которые затем развертываются в Kubernetes API. При этом создается релиз, то есть конкретная конфигурация и развертывание для конкретного пакета.

      Понимание концепции релизов очень важно, поскольку одно и то же приложение можно развернуть в кластере несколько раз. Например, вам пожет понадобиться несколько серверов MySQL с разными конфигурациями.

      Возможно вы захотите обновлять разные экземпляры пакета по отдельности. Одно приложение может быть готово работать с обновленным сервером MySQL, а другое — нет. С помощью Helm вы можете обновлять каждый релиз по отдельности.

      Вы можете обновить релиз в связи с обновлением пакета или в связи с необходимостью обновить конфигурацию релиза. При каждом обновлении создается новая редакция релиза, и в случае возникновения проблем Helm позволяет легко возвращаться к предыдущим редакциям.

      Создание пакетов

      Если вы не можете найти существующий пакет для своего программного обеспечения, вы можете создать собственный пакет. Helm может вывести схему каталога пакетов с помощью команды helm create chart-name. При этом будет создана папка с файлами и каталогами, которые мы обсуждали в разделе «Пакеты» выше.

      Теперь вы можете заполнить метаданные пакетов в файле Chart.yaml и поместить файлы манифеста Kubernetes в каталог templates. В этом случае вам нужно извлечь переменные конфигурации из манифестов в файл values.yaml, а затем включить их в шаблоны манифеста с помощью системы шаблонов.

      Команда helm имеет множество субкоманд для тестирования, упаковки и обслуживания пакетов. Дополнительную информацию можно найти в официальной документации Helm по разработке пакетов.

      Заключение

      В этой статье мы рассмотрели диспетчер пакетов Helm для Kubernetes. Мы рассмотрели архитектуру Helm и отдельные компоненты helm и tiller, рассказали о формате пакетов Helm и привели обзор репозиториев пакетов. Также мы рассмотрели процедуру настройки пакетов Helm и объединение конфигураций и пакетов и их развертывание в качестве релизов на кластерах Kubernetes. В заключение мы рассказали об основных процедурах создания пакетов в случаях, когда готовых пакетов нет.

      Дополнительную информацию о Helm можно найти в официальной документации по Helm. Официальные пакеты Helm можно найти в официальном репозитории Git helm/charts на GitHub.



      Source link