Привет!

Я Давид Бадалян, работаю в Исследовательском центре доверенного искуственного интеллекта ИСП РАН. В статье я хочу поговорить об Ansible – одной из самых популярных систем по автоматизации развёртывания. 

Стоит запустить Ansible программно, и он становится черным ящиком – нет никакого контроля над его выполнением, нет информации о тасках. Эту проблему мы обнаружили, разрабатывая оркестратор Michman для сервисов уровня PaaS. В результате мы создали cotea и gocotea: инструменты для программного исполнения Ansible-плейбуков из языков Python и Go.

Про cotea, её архитектуру и кейсы применения я расскажу подробно под катом. Если вы DevOps-инженер и хотите узнать, как можно гибко использовать Ansible – статья точно для вас.

Привет, Хабр! На связи автор статьи двухлетней давности «Пожалуйста, прекратите называть админов девопсами». В ней, если помните, я ловил пескарей в процессе поиска работы офигевал от несоответствия реального мира и моих онтологических ожиданий. С тех золотых денёчков изменилось примерно всё — и вот, с учётом полученного за прошедшее время опыта я хотел бы оглянуться, посмотреть назад и понять, выдержали ли мои прошлые соображения проверку временем.

Привет, Хабр! Меня зовут Александр Лукьянченко, я тимлид команды, которая занимается платформой в Авито. В этой статье я расскажу о проблемах, которые возникали у нас при построении платформы для инженеров и том, какие технические решения мы использовали, чтобы эти проблемы устранить. Текст охватывает ту часть наших наработок, которые потенциально можно переиспользовать другим компаниям.

Можно ли построить удобный для всех pipeline, приложив усилия один раз, а не 100? Об этом расскажет Виктория Вольферц. Она работает в БКС DevOps-инженером в управлении микросервисной архитектуры. БКС предоставляет брокерские и банковские услуги для клиентов. Их основные продукты — это мобильное приложение БКС Мир Инвестиций и веб-кабинет для клиентов.

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

Привет, меня зовут Ярослав Иссинский, я руководитель Технической платформы в группе «М.Видео-Эльдорадо». Сегодня я хочу рассказать про переход в публичное облако на примере крупной ритейл-компании.

Александр Крижановский ( krizhanovsky, NatSys Lab.)

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.

Ого! Как много информации.

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

• Проверка каждой ветки проходила локально. Приходилось откатывать базу от изменений с предыдущей проверки, билдить фронт. Когда несколько разработчиков вот-вот закончат работы и осталось проверить каждую по мелочи — это превращалось в ад;
• Различались окружения на проде и между разработчиками, что приводило к ошибкам: “у меня всё работает”.

Внутренний перфекционист жаждал организовать всё правильно. Делюсь результатами поисков ответа на вопрос: «а как, собственно, “правильно”»?

Мы добились

• Легкого и быстрого деплоя в production (ради эксперимента выводили каждый день две недели подряд);
• Гарантию защищённости от ошибок из-за различий в окружении приложения;
• Можем организовать эффективное взаимодействие с заказчиком:
  
  • демонстрировать каждую feature-ветку;
  • давать гостевой доступ для создания задач и наблюдения над ходом работ.

Данная статья будет полезна, если вы:

• начинающая IT-компания или в первый раз столкнулись с работой в команде над большим проектом;
• хотите обновить свой устаревший процесс разработки (workflow);
• ищете лучшие практики и хотите посмотреть, как у других;
• часто натыкаетесь на статьи про DevOps, CI/CD, облака и хотите, чтобы у вас одним нажатием кнопки создавались тестовые окружения, а очередное обновление прода не было рулеткой.

Под катом вы найдёте

• типовой рабочий процесс от постановки задач до релиза;
• инфраструктурное решение для построения любого современного процесса разработки с использованием минимального количества инструментов;
• пример для часто встречающегося кейса: разработка веб-приложения;
• видеозапись доклада, где вживую показывается результат.

Структура обзора

Введение

• 4000 хостов в сети
• Коммутаторы уровня доступа: Cisco Catalyst 35xx (~2500 портов)
• В центре оптический коммутатор Cisco Catalyst 6500
• Беспроводные точки доступа Cisco разных моделей (~1500 клиентов ежедневно) под управлением контроллера Cisco 44xx
• В интернет выпускает маршрутизатор Cisco 38xx
• В сети создано более 50 vlan-ов