Заявки на доклады

Поиск по тегам:

Управление конфигурацией

Terraform modules inside out

Anton Babenko

Terraform module is the smallest reusable component of an infrastructure. Getting started to use modules is easy, but keep them in a good shape and make them really powerful is harder.

Your infrastructure almost always starts simply: few resources managed by few developers. As time goes it grows in all possible directions. You found your ways around grouping resources into Terraform modules, so what can possibly go wrong? (famous last words)

During the talk, I will explain several unknown, hard to find and rather green-field solutions related to Terraform modules. More specifically:
- Types of modules (resource and infrastructure modules, compositions)
- How to specify dependencies between modules
- Workflow for various types of modules

More advanced topics like:
- Refactoring, upgrades, rollbacks (without recreation of the resources)
- Poor-man modules manager
- What are the limitations of the current implementation of Terraform modules and workarounds (eg, jsonnet, cookiecutter, terrapin)

I will demonstrate and run the code which handles advanced problems based terraform-aws-modules from the Terraform Registry and explain why hundreds of developers are using those modules already (btw, they were downloaded 1 million of times already).

Программный комитет ещё не принял решения по этому докладу

Миграция backend’а на Kubernetes или К вопросу о том, есть ли жизнь в production после внедрения K8S

Seva Morotskiy

В докладе будут рассмотрены use cases, когда развитие сложной ИТ-инфраструктуры продукта привело к новым вызовам, ответом на которые стало создание инфраструктуры, основанной на Kubernetes и Docker.

Мы поговорим о следующих проблемах, с которыми команда столкнулись в ходе реализации проекта, и о путях их решения:
• особенности написания custom tools для деплоя инфраструктуры системы и аргументы в поддержку переписывания данных tools на скрипты ansible;
• нюансы работы weave-сетей через WAN в K8S-кластерах;
• использование шифрования в weave-сетях для безопасного общения компонентов K8S-кластера между собой;
• фиксация/стабилизация версии kubeadm, weave и других компонент Kubernetes-инфраструктуры для обеспечения гарантии их корректной работы друг с другом;
• отказ от федерализации кластеров Kubernetes;
• безопасность хранения AWS-ключей на отдельных серверах инфраструктуры системы и контроль доступа компонентов системы, которые имеют full access к consul-кластеру для доступа к конфиг-данным системы;
• использование шаблонизаторов для установки K8S chart’ов и корректная генерация values-файлов для chart’ов;
• запуск Prometheus на каждом Kubernetes-кластере системы (backend/client-кластерах) и сложность консолидации этих данных в рамках центрального Prometheus-сервера;
• Prometheus vs InfluxDB – к вопросу о хранении оперативных и исторических данных.

Программный комитет ещё не принял решения по этому докладу

Непрерывное развертывание и деплой

.NET на Linux, а DevOps на коне

Александр Синчинов

В своем докладе я расскажу на примере реализованного проекта для крупного заказчика с более 100 000 конечных пользователей, как играючи доставлять проект в rpm, используя TFS, Puppet, Linux .NET core, и о том, как поддерживать версионирование БД проекта, если разработка впервые слышит слова Postgres и Flyway, а дедлайн послезавтра. О сломанных костылях и работающих решениях.

Расскажу о том, как мотивировать .NET-разработчиков отказаться от Windows и смузи в пользу Puppet и Linux, и что делать, когда ты девопс и обслуживать винду в продакшне нет ни сил, ни желания, да и ресурсы не резиновые. О методах разрешения идеологических конфликтов.

Как готовят TFS в Золотой Короне. Расскажу о практиках использования TFS в существующих проектах. Как интегрированы с Docker, о Web deploy, тестировании и CI.

Программный комитет ещё не принял решения по этому докладу

Делаем CI для мобильного SDK с нуля

Артем Никитин

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

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

Список ключевых слов: Jenkins, AWS, Serverless, Docker, Mac mini, git, repo, Gerrit, Java, Go

Работа с Amazon
,
Критерии выбора технологий для проекта
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Особенности процессов разработки и тестирования мобильного ПО
,
Кросплатформенная разработка
,
GO
Программный комитет ещё не принял решения по этому докладу

Где застревает софт? Применение измерений и системного анализа для выявления узких мест в конвейере доставки ПО

Антон (Энт) Вайс

Гибкое управление, бережливое управление, непрерывная интеграция, наконец - ДевОпс! Чего только мы не предпринимали для оптимизации сроков доставки ПО. Преимущество ДевОпс-принципов заключается в том, что они собрали в себе весь опыт предыдущих, не всегда, мягко говоря, удачных попыток.

Теория ограничений научила нас, что оптимизация цепочки доставленной ценности в любом месте, кроме самого узкого (так называемого бутылочного горлышка), не приведет к лучшим результатам. А зачастую и наоборот - приблизит крах.

ДевОпс зиждется на системном анализе и измерениях.

На лекции мы рассмотрим все части конвейера доставки ПО и обсудим:
* что измерять,
* как измерять,
* как использовать системный анализ для выявления этих узких мест.
* и как это поможет вам в оптимизации сроков доставки ценности вашей ИТ-организации.

Совместная работа, система контроля версий, организация веток
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Выбор стратегии долгосрочного развития, KPI
,
Управление / другое
Доклад принят в программу конференции

Foreman, Smart Proxy и разработка плагинов

Анатолий Чмыхало

- Что такое Foreman?
- Как и где использовать Foreman.
- Что такое Smart Proxy?
- Что такое плагины для Foreman Smart Proxy?
- Пошаговая разработка DHCP-плагина.
- Деплой плагина и результат работы.

API
,
Прочие языки
,
Бэкенд / другое
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Реальные юзкейсы применения serverless-подхода для решения инфраструктурных задач

Артем Никитин

В докладе мы рассмотрим применение подхода serverless на примере AWS Lambda для решения различных практических задач связанных с инфраструктурой.
Примеры задач которые мы решаем Lambda'ой:
- Поддержание AMI в обновленном состоянии (решение похоже на Packer от HashiCorp, но с нашей спецификой)
- Отправка фидбека от CI в код ревью
- Выключение неиспользуемых EC2 инстансов
- Микросервис для сбора метрик и др.
В докладе будет рассмотрено как практическое применение AWS Lambda так и затронуты вопросы тестирования, деплоя и мониторинга serverless приложений

Java
,
Работа с Amazon
,
Непрерывная интеграция
,
Devops / другое
,
GO
Программный комитет ещё не принял решения по этому докладу

Технологии отказоустойчивости и катастрофоустойчивости

Ceph. Анатомия катастрофы

Артемий Капитула

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

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

Программный комитет ещё не принял решения по этому докладу

Управление в эксплуатации

Главное не качество, а количество!

Егор Бугаенко

I truly believe that quality is not what programmers should care about. They must care only about speed—close tasks as soon as possible— which means make money. Won't this attitude ruin the project and turn the code base into a mess? Yes, it will. If the project doesn't care about its quality either. There must be a permanent conflict between a project and its programmers: 1) the project must be configured to reject anything that lowers the quality of its artifacts and 2) programmers must be interested in making changes to those artifacts. The project cares about the quality, the programmers care about fast delivery of modifications.

I wrote about this: http://www.yegor256.com/2018/03/06/speed-vs-quality.html

Программный комитет ещё не принял решения по этому докладу

Почему надежные дата-центры не надежны, или как выбирать на берегу?

Игорь Мызгин

В последнее время есть традиция, что почти каждую пятницу в ФБ идут очередные войны вида "ААА!!!111адинадинадин хостинг-провайдер XXXXXX упал! мы теряем миллионы! срочно спасите-помогите!!!".

В данном докладе я постараюсь систематизировать ответы на ряд вопросов:
1) какие хостинг-провайдеры бывают;
2) чем они отличаются;
3) какие "типовые" маркетинговые уловки есть в самопиаре большинства провайдеров;
4) как сравнить провайдеров до того, как вы начнете с ними работать (два переезда равны одному пожару - это и про миграцию с хостера на хостера тоже верно);
5) что такое Tier 2-3-4 и, вообще, какие сертификации / внешние рейтинги / независимые оценки "качества" для хостеров бывают?
6) что важно и не важно и на что посмотреть ДО, чтобы потом не задавать вопросов вида "но ведь нам же обещали в договоре два независимых дата-центра, почему же мы лежим?" в паблике ФБ.

По опыту предыдущих докладов - половина времени будет посвящена слайдам, вторая половина - ответам на вопросы аудитории.

Работа со внешним заказчиком/исполнителем
,
Работа с зарубежным заказчиком/рынком
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Программный комитет ещё не принял решения по этому докладу

Рефакторинг эксплуатации

Владимир Буянов

Что делать, когда приходишь на проект и видишь, что степень его автоматизации и количество костылей в его поддержке можно описать словами “Деплоить - это просто как ездить на велосипеде, который горит. И ты горишь, и всё горит, и ты в аду”, а все инфраструктурные инструменты делятся на 2 типа: уже EOL и “написаны на коленке и никогда и не поддерживались”.

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



Программный комитет ещё не принял решения по этому докладу

DevOps by nature. How do we learn from ants and bees?

Mark Heistek

As a biomimicry expert I believe in changing in an organic way by empowering people.
In DevOps we talk a lot about culture and how to create a culture of continuous improvement. All to serve our clients best and to become an agile and sustainable organization.
Nature is agile and sustainable for 3.8 billion years. In this talk I will take nature as our DevOps teacher. Where do we find DevOps in nature and how can she teach us to become more DevOps. I will use some great DevOps examples of e.g. ants and bees, but there is more we can learn.
I will also provide some examples where I used nature as source of inspiration to lead a DevOps transition.

Программный комитет ещё не принял решения по этому докладу

Terraform best practices with examples and arguments

Anton Babenko

This talk is for the developers who want to learn best practices in using Terraform at companies and projects of various size (from small to very large), get pros&cons on code structuring, composition. Also, attendees will be able to learn Terraform (and Terragrunt) tricks and gotchas.

It is easy to get started with Terraform to manage infrastructure as code. Just read the documentation on terraform.io, and you are done. Almost.

The harder part begins when infrastructure grows in all directions (several AWS/GCP accounts, regions, teams, projects, environments, external integrations). One of the most frequent questions is "how to structure code".

In this talk, I will explain many of challenges related to that, what works, what does not work, why so, and most importantly I will show all the code which works from small projects to very-large infrastructures (featuring multi-cloud and multi-region setup).

This talk is best suitable for people who have been using Terraform at least for some time and already have practical questions.

All the code and solutions presented at the workshop will be open-sourced.

Программный комитет ещё не принял решения по этому докладу

Частые ошибки архитекторов и администраторов Ceph

Михаил Плужников

В докладе рассказывается о основных ошибках при проектировании и эксплуатации Ceph, с которыми сталкиваются архитекторы и начинающие администраторы.

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

Программный комитет ещё не принял решения по этому докладу

Sudo install DevOps

Mark Heistek

Let’s do DevOps because it sounds cool and you are cool if you do it. But how to implement DevOps? Can you implement DevOps? What is DevOps anyway?

DevOps is not an implementation. You cannot just simply give the command “sudo install DevOps”. Moving towards a DevOps organisation is a journey. A journey with a lot of success and even more failures.

This talk will bring you on this journey of successes and failures and provide you insights of real DevOps transitions.

Программный комитет ещё не принял решения по этому докладу

Технологии виртуализации и контейнеризация

Внутренняя архитектура Кубернетеса для администраторов

Ben Tyler

Вы - сисадмин, SRE или devops-инженер. Ваша компания только что решила эксплуатировать Кубернетес, и теперь вам придется поддерживать эту систему всерьез. Большинство ресурсов про Кубернетес описывают его как фантастическую технологию, данную нам волшебниками из Гугла. Возможно, что да — штука крутая и полезная, принесет значительную пользу. Но администраторы знают: солнце встает на востоке, и сложные распределенные системы отказывают в продакшне. Приходит смутное время.

Цель этого доклада - составить рабочее представление о главных компонентах Кубернетеса и взаимодействии между ними. Рассмотрим такие вопросы, как:
* что за «контроллеры»?
* как они реагируют на разрыв соединения с API-сервером?
* какую роль играет kubelet, и что ожидается от него при потере кворума etcd?

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

Программный комитет ещё не принял решения по этому докладу

Как переехать с ESXi на KVM/LXD и не сойти с ума

Лев Николаев

Во многих организациях в качестве гипервизора используется VMware в разных его ипостасях. Чаще всего в его бесплатном виде - в виде ESXi. У себя в операторе связи мы использовали его достаточно давно, начиная с версии 5.0.

Разумеется, что у бесплатной версии есть ряд недостатков, которые успешно отсутствуют в платной версии продукта vSphere, однако модель лицензирования достаточно отпугивающая для малого бизнеса. А самое главное, что новые версии ESXi принесли целый ряд неудобств:
- веб-интерфейс, который не работает нормально (старый программный интерфейс не совместим с новыми версиями);
- сломан нормальный мониторинг RAID-массивов.

В итоге стало очевидно, что нужно сваливать и искать более универсальное и более открытое решение.

У нас уже был достаточно неплохой опыт и приятное впечатление от LXC, Linux Containers. Поэтому стало очевидно, что гипервизор мечты будет гибридным, т.е. сочетать для разных нагрузок KVM и LXD, эволюционное продолжение LXC.

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

О чем будем говорить в докладе:

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

2. Хранилище
Сделайте общее сетевое хранилище. Даже если вы не готовы внутри сети использовать 10 Gbps, то даже 1 Gbps даст Вам 125 мегабайт в секунду стораджа. Для целого ряда нагрузок этого будет достаточно за глаза, а миграция виртуальных машин станет элементарным делом.

3. Контейнер или KVM?
Плюсы, минусы, подводные камни. Какие виды нагрузки лучше положить в контейнер, а какие лучше оставить в KVM?

4. LXD или LXC
А ведь LXD это LXC? Или это другая версия? Или надстройка? Или что это вообще? Развеиваем мифы и поясняем на пальцах, в чем заключаются отличия между LXD и LXC.

5. Удобный provisioning
Что удобнее: брать одинаковый образ или инсталлировать систему с нуля каждый раз? Как это делать быстро, четко, ровно каждый раз?

6. Как делать виртуалку хорошо внутри?
Здесь будут страшные рассказы о загрузчиках, разделах, LVM и прочем ужасе.

И еще куча всяких мелких вопросов:
- как быстро перетащить виртуалку c ESXi на KVM?
- как хорошо мигрировать?
- как правильно виртуализировать диски?

Программный комитет ещё не принял решения по этому докладу

Кто живет на облаках, или что такое cloud-native infrastructure

Антон (Энт) Вайс

Облачные инфраструктуры пару лет как перестали быть инновацией. Сегодня вопрос уже не : “Лезть ли нам на облако?”, а “Как правильно жить в облаках?”.

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

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

Именно это мы и обсудим:
* Что такое cloud-native infrastructure.
* Что такое cloud-native applications.
* Какие проекты входят в CNCF и почему.
* Зачем нужен service mesh.
* Чем "infrastructure as software" отличается от "infrastructure as code".
* Как все это проверять
* Как все это связано с ДевОпс.

API
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Распределенные системы
,
Логирование и мониторинг
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Web-scale IT / другое
Программный комитет ещё не принял решения по этому докладу

Логирование и мониторинг

Revenue Based Monitoring

Василий Озеров

Все ИТ-компании давно пришли к тому, что необходимо собирать как много больше метрик из происходящих вокруг процессов. Я говорю не только о технических показателях, таких как количество запросов и cpu usage, но и о бизнес-метриках, таких как revenue, retention, quality и прочих.

К сожалению, очень часто эти метрики анализируются отдельно друг от друга, и никто не пытается их соотнести. Знаете ли вы, сколько денег вам приносит веб-сервер? Как увидеть проблемы, когда все системы технического мониторинга горят зеленым? Сколько денег теряет бизнес, когда база данных загружена на 90%? А на 50%?

Если интересно узнать про наш опыт - приходите, будет жарко!

Программный комитет ещё не принял решения по этому докладу

Мониторинг системы - дело рук самой системы

Руслан Зиганшин

В своем докладе я расскажу о том, как зарождалась, развивалась и интегрировалась в существующие операционные процессы прикладная подсистема мониторинга ЦФТ-Банк:
* Почему родилась идея реализовать мониторинг внутри прикладной подсистемы.
* Как развивалось реализованное техническое решение.
* С какими проблемами в процессе эксплуатации мы столкнулись и как их победили.
* Какие преимущества мы получили, и как изменился наш подход к процессу мониторинга программно-аппаратного комплекса.
* Что ждет подсистему мониторинга в дальнейшем.

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

Программный комитет ещё не принял решения по этому докладу