Архивы DevOps - Страница 2 из 3

Используем Docker для python приложения

Технология контейнеризации Docker – своеобразная священная корова последних лет в области Информационных Технологий. Именно с помощью Docker и различных систем управления для контейнеров получается реализовать самые высоконагруженные системы в мире. Также заметно упрощается процесс разработки приложений. В свое время уже писал в блоге статью из этой области – Docker в повседневной работе ITшника. Сейчас хотелось бы немного больше осветить практическую часть вопроса. А именно способ запуска python приложения в Docker контейнере на сервере. При этом подразумевается, что Вы не используете инфраструктуру наподобие Kubernetes или его аналогов, а просто хотите по мере необходимости использовать контейнеры от случая к случаю. Частенько бывает ситуация, что сервер для различных задач задействует возможности Python v2. При этом есть существенная необходимость запускать приложения, написанные на Python v3. Использование Docker позволяет элегантно решить эту задачу.

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

Управляем логами с ELK

Сколько себя помню в IT профессии, анализ и обработка логов – были всегда актуальной задачей. Оборудование и программное обеспечение постоянно генерируют лог записи о своей жизнедеятельности. И чем больше у Вас техники под управлением, тем больше массив данных, который ежедневно генерируется. Раньше были очень дорогие платные решения, типа HP ArcSight Logger, а также бесплатные опенсорсные как Adiscon LogAnalyzer. Но если первый тип продуктов, во-первых, был очень дорогим и недоступным для многих, а во-вторых, крайне “тяжелым” в эксплуатации. То второй тип программного обеспечения давал очень мало нужного функционала, слабо масштабировался и плохо проводил аналитику имеющихся логов. С приходом на IT сцену ELK – картина радикально поменялась. ELK или комплекс продуктов на базе Elastic Stack эффективно позволяет решать любые задачи с обработкой, хранением и визуализацией массивов логов различных устройств и программного обеспечения.

Сам по себе стек Elastic состоит из ряда отдельных продуктов, таких как Elasticsearch, Kibana, Logstash и ряда других. Однако все они взаимодополняют друг друга, работая как одно общее целое. Поэтому, принято говорить о работе всего стека ELK, который обрабатывает массив поступающей информации, позволяя ее эффективно анализировать и визуализировать. Elasticsearch – это ядро всего этого комплекса, которое отвечает за поиск нужной информации во всем массиве данных. Kibana – красивая визуальная среда, которая позволяет комфортно взаимодействовать с системой ELK ее пользователям. Ну а Logstash – это программное обеспечение, ответственное за прием данных из внешних источников и их обработку таким образом, чтобы дальше было легко их искать и анализировать.

Подсказки по утилите Git

Уровень проникновения инфраструктуры Git, GitHub, GitLab в ITшную работу и жизнь просто колосальный. С этими системами приходится сталкиваться постоянно в том или ином виде. Утилита git в современных операционных системах идет, как правило, предустановленной. При желании или необходимости она легко устанавливается из исходников или различных репозитариев. Git – сегодня представляет не просто фреймворк для системы контроля версия, а целую философию и своеобразную экосистему для всех разновидностей программного кода. Для того, чтобы нормально работать с этой платформой нужны определенные базовые знания. Составил для себя основные команды утилиты git, которые применяются в работе. Для ведения локальной разработки этих возможностей на первом этапе будет достаточно.

Тестируем Ansible роли с Molecule

Времена меняются, системные администраторы постепенно становятся DevOps-ами. И соответственно в работу администратора постепенно проникают элементы программирования и QA тестирования. Так при написании Ansible ролей, можно самому проверять их с использованием виртуальных машин или используя автоматизацию на Vagrant. Однако, программный продукт Molecule позволяет еще более комплексно автоматизировать процесс тестирования. А кроме того добавляет возможность по созданию собственных функциональных тестов с помощью модулей testinfra и pytest. То есть мало того, что Molecule автоматически проверит работоспособность действий из Ansible роли, но и запустит специфичные тесты, которые придется написать нам самим, по проверке состояния тех или иных частей системы, после отработки роли. Таким образом, часть нашей работы превращается в настоящее QA тестирование. И что самое интересно, это необходимая работа, без которой не обойтись в современных реалиях. Ansible роли могут применяться на сотнях и тысячах серверах, их полноценное тестирование просто необходимо для дальнейшей спокойной работы.

TDD – Test Driven Development, подход к работе при котором происходит постоянное тестирование для проверки работоспособности программного кода. В нашем случае использование Molecule для Ansible ролей позволяет вести профессиональную их разработку по методике TDD. Это обеспечивает постоянную целостность и корректность создаваемого кода.

Стыкуем Vagrant и vSphere

Про систему HashiCorp Vagrant я уже ранее писал в этом блоге в статье – Vagrant — основы работы. Там мы разобрали как развернуть Vagrant и начать работу на базе облака Amazon AWS. Однако, возможности Vagrant охватывают и множество других систем по запуску виртуальных машин. Виртуализация на базе VMware vSphere распространена повсеместно в организациях в нашей стране. Vagrant может стыковаться и работать как с отдельными хостами гипервизоров VMware ESXi, так и с системой управления VMware vCenter. При этом при запуске будет запускаться виртуальная машина в системе виртуализации VMware, на которой мы сможем проводить необходимые тестовые работы. А после проведения необходимых работ, виртуальная машина будет полностью удаляться. И во время этого процесса никаких действий в интерфейсе VMware vSphere нам выполнять не придется.

Vagrant – основы работы

Один из необходимых инструментов в повседневной работе администратора или программиста – Vagrant. Эта небольшая утилита позволяет оперативно запустить виртуальные машины для нашей тестовой среды. При этом Vagrant поддерживает различные тестовые среды. Начиная от системы виртуализации VirtualBox, и вплоть до различных провайдеров публичных облаков, таких как Amazon AWS. Vagrant – очередной инструмент, созданный HashiCorp. Это пожалуй, один из наиболее старых продуктов, который использует методологию Infrastructure-as-a-Code. Данный продукт не является аналогом Terraform или CloudFormation. Он не хранит в себе данных о различных сервисах облака. Его основная задача – оператвный запуск и остановка вычислительных ресурсов для проведения тестовых работ.

Ранее уже поднимал тему IaaC, а также инструментов, которые используются для этого. Это были статьи о Terraform (Автоматизируем облако с Terraform) и Packer (Создаем образ ОС с Packer). С помощью Packer мы создаем образы виртуальных машин, которые после этого можем использовать в Vagrant для запуска работы наших приложений. Он может при своей работе задействовать возможности Ansible. Часто можно услышать вопрос, а зачем это нужно, когда и так можно запускать виртуалки без дополнительного софта. Однако, Vagrant при частом использовании хорошо экономит время и добавляет лишнее удобство в работе.

Создаем образ ОС с Packer

При работе в облаке или в системе виртуализации очень часто необходимо создание определенных “золотых” образов операционных систем. Данные образы позволяют запускать виртуальные машины с нужными готовыми настройками и установленным программным обеспечением. Чем больше виртуальных машин в инфраструктуре Вы используете, тем актуальнее такие золотые образы для Вас. Экономия времени в работе выходит колоссальная. Также, например, для меня при тестировании той или иной технологии часто нужно бывает оперативно поднять одну или несколько виртуалок. Желательно это сделать быстро. В связке с Vagrant, Ansible, программный продукт Packer от HashiCorp великолепно справляется с этой задачей. Он позволяет из исходного образа виртуальной машины подготовить необходимый для наших целей “золотой” образ.

Эта статья является логическим продолжением темы IaaC, которую я поднял в “Автоматизируем облако с Terraform”. Здесь, как и в той статье, мы также рассмотрим продукт компании HashiCorp. Сама компания, возглавляемая Mitchell Hashimoto, продвигает в последние годы несколько интересных идей, которые реализуются в рамках парадигмы Infrastructure-as-a-Code. В этой статье мы разберем относительно небольшой программный продукт Packer. По сути у него только одна задача – создание загрузочного образа виртуальной машины под конкретную среду облака или виртуализации. С этой задачей Packer справляется блестяще. Он позволяет работать с облаками Amazon, Azure, GCP, виртуальными машинами VMware, контейнерами Docker.

Автоматизируем облако с Terraform

Облачные технологии с точки зрения концептуального технического подхода предлагают совершенно иной взгляд на управление IT инфраструктурой. Мы теперь не беспокоимся о том, как работает оборудование, как подключены между собой сервера и СХД, кто и каким образом установит операционную систему и драйвера. Главное внимание теперь уделяется непосредственно нашим приложениям и сервисам. Программный продукт Terraform от HashiCorp позволяет эффективно организовывать необходимую нам IT инфраструктуру в облаке и изменять ее в случае надобности с помощью текстовых конфигурационных файлов. Такой подход в работе называется IaaC – Infrastructure-as-a-Code. Все, что нужно знать при таком подходе, для разворачивания нашей инфраструктуры – правила и параметры по созданию нужных сервисов в облаке.

IaaC (Infrastructure-as-a-Code) – подход к работе с IT инфраструктурой, который заключается в том, что создаваемая и поддерживаемая нами инфраструктура представлена в текстовом файле в виде кода. Этот подход подразумевает использование облачной или виртуализованной инфраструктуры под собой, при котором нет необходимости взаимодействовать непосредственно с аппаратным обеспечением. Для создания того или иного элемента инфраструктуры, мы просто добавляем нужный код с описанием этого элемента. Избавляясь от проблем с настройкой и поддержанием реального железа, мы заметно увеличиваем производительность труда инженеров и сисадминов.

Коммандная строка для облака – AWS CLI

Облачные технологии так или иначе занимают прочное место в IT инфраструктуре организаций. Я говорю в первую очередь о передовых компаниях, которые работают на мировом уровне. Для большинства местных Узбекских компаний публичные облака на сегодняшний день – это все таки редкость. При использовании публичных облаков, компания получает массу преимуществ: нет необходимости содержать свою сложную IT инфраструктуру, платить за лицензии, думать об отказоустойчивости, нанимать различных дорогих квалифичированных специалистов для поддержания всей этой инфраструктуры. Мы по сути сразу берем абстрагированные необходимые вычислительные мощности и используем их под свои приложения.

В этой статье хочется поговорить о сервисах публичного облака Amazon – AWS. А точнее об интерфейсе коммандной строки для управления этими сервисами aws cli. По моему мнению, AWS – это одни из лидеров, если не сказать, что они самые главне пионеры в развитии сервисов публичных облаков. То, что они делают, является примером для всех других игроков в этой области. При обилии имеющихся сервисов и возможностях по их настройке через веб интерфейс, коммандная строка aws cli заментно ускоряет работу по настройке этих сервисов и взаимодействию с ними. Также коммандная строка просто незаменимый инструмент при автоматизации процессов с облаком Amazon.

Управляем серверами локально через Ansible

Количество серверов (физических и виртуальных), которыми необходимо управлять, как правило, у каждого администратора месяц от месяца только прибавляется. Даже если у Вас нету в организации сервисов, которые работают по понятиям HighLoad, то наверняка количество IT систем постоянно растет. Для того, чтобы оставаться эффективным в современных условиях, использование какой-либо из систем управления конфигурациями просто необходимо. Ansible – одна из таких систем, которая по моему мнению, по своим возможностям и архитектурным особенностям лучшая на сегодняшний день.

Использовать этот программный продукт можно как на сервере, так и с локального ноутбука или настольного компьютера. Из основных требований – наличие интерпретатора Python и нескольких модулей для корректной работы Ansible. Мне бы хотелось тут показать, как можно настроить это ПО таким образом, чтобы без использвоания учетной записи root, выполнять любые действия на своих серверах на локальном компьютере без необходимости вводить пароли.