-
Notifications
You must be signed in to change notification settings - Fork 0
/
text.txt
142 lines (110 loc) · 18 KB
/
text.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
Всем привет!
Меня зовут Денис и я работаю команде Infrastructure & Operations в компании 2 ГИС.
Наша команда:
- Занимается тем, что поддерживает внутреннюю инфраструктуру веб отдела компании
- Отвечает за эксплуатацию продуктов компании в датацентрах
- А так же занимается исследованием и разработкой новых инструментов, как для своих целей, так и для улучшения процессов разработки
И сегодня я предлагаю поговорить об инфраструктуре. Я расскажу:
- Какая у нас была ситуация
- Как мы ее изменили
- Какие уроки извлекли
Но сначала давайте посмотрим, а почему мы вообще говорим об инфраструктуре.
Итак, буквально с первых шагов работы над продуктом у нас возникает вопрос: куда деплоить или где мы будем смотреть результаты.
Первый ответ который приходит сразу же в голову, это, конечно же - локально.
Это достаточно просто - в одном месте и разрабатываешь и проверяешь.
А если на рабочей станции стоит одна операционная система, а в продакшне установлена другая?
Или продукт должен поддерживать несколько операционных систем?
Ок, этот вопрос можно решить следующим образом - пусть у нас будет только определенный дистрибутив Linux.
Неплохая попытка! Но просто совпадения операционных систем недостаточно. Нужно чтобы совпадали все установленные либы, пакеты и т.д.
Есть другое решение - локально, с изоляцией. Слава богу сейчас есть много программного обеспечения позволяющего это сделать.
Мы можем создать виртуалку в Virtualbox с нужной нам осью и деплоить туда и свой продукт и все необходимые для него зависимости.
При этом мы работаем в нашей любимой оси и никаких лишних библиотек или пакетов на нашей рабочей станции нет.
А теперь представьте, что мы растем, развиваемся, продукты становятся более сложными, появляются новые продукты, команды.
Все друг с другом хотят интегрироваться, появляется желание тестировать все автоматически, для этого нужен дополнительный софт и т.д.
В общем локального окружения, своих личных виртуалочек перестает хватать.
Нужно какое то общее место где все могли бы легко создавать виртуальные окружения, деплоить свои продукты и делать там с ними все, что нужно.
И в этот момент у нас собственно и появляется та самая инфраструктура, которая в последствии и станет очень критичным аспектом в разработке продуктов.
Итак, теперь вернемся к 2ГИС. Для тех, кто не знает - 2ГИС это Справочник и карты. У нас есть как Web продукты, так и мобильные и desktop приложения.
И что мы имеем - у нас есть несколько платформ, 35 команд разработки разной величины и, соответственно, примерно столько же проектов.
И на конец 2013 года мы имели следующую ситуацию:
В компании использовался Proxmox - это система виртуализации, где вручную через интерфейс можно создавать виртуальные машины для гипервизора KVM
или контейнеры для гипервизора OpenVZ. Помимо этого для нормального функционирования виртуалки надо было вручную настроить сеть и DNS.
Следовательно чтобы заполучить себе виртуалку необходимо было завести тикет админам. Они через какое то время ее сделают.
Если с этой виртуалкой что-нибудь случается, то надо опять идти к админам просить, чтобы ее пересоздавали и т.д.
Так как все это делалось руками, то такой кейс, как проверка деплоя продукта с нуля непроверялся очень давно.
Помимо этого не было разделения по проектам. Виртуалки принадлежали непонятно кому, непонятно нужна эта виртуалка в данный момент или же о ней забыли.
Автоматизации небыло по причине слабого API, а плагины либо платные, либо на Perl`e.
Все это существенно замедляло процесс доставки новых фичей и являлось причиной большой нервозности в коллективе. Нужно было что то менять.
Однако не все так плохо, у нас были не только проблемы, но и кое что полезное.
А именно:
У нас было и есть свое железо.
У нас были и есть люди, которые умеют обращаться с этим железом: умеют его настраивать, следить за ним и закупать новое.
И у нас был опыт работы с виртуализацией.
Мы решили провести исследование на тему того - а что же мы хотим вообще от инфраструктуры. Какой она должна быть, чтобы не тормозить процесс разработки,
а наоборот помогать. В итоге исследования мы сформулировали требования к решению:
- Решение должно позволять нам эффективно утилизировать железо. Мы не хотим просто греть воздух в датацентрах.
- Каждая команда должна самостоятельно следить за своими ресурсами.
- Решение должно быть гибким. Мы хотим из кубиков собрать нужный нам функционал и в дальнейшем, при необходимости, добавить новый
- Нужно иметь возможность доработать решение под наши специфичные нужды
- Чтобы с ним было удобно работать программно нужен полноценный API
- И команды не должны мешать друг другу. Особенно при тестировании производительности
Сформулировав данные требования, мы, скрестив пальцы, стали искать решение. Очень не хотелось писать свое с нуля.
Какие варианты возникли перед нами?
Первое это, конечно же, публичные облака типа AWS, Digital Ocean и т.д. Вариант привлекателен тем, что берет все инфраструктурные вопросы на себя,
но отталкивает потому что оплачивается в долларах. К тому же у нас уже есть свое железо.
Есть вариант купить полноценное решение от таких компаний как VMware, HP, но мы хотели максимально избежать vendor lockin и опять же доллар.
Поэтому мы остановились на третьем варианте - выбрать open source решение.
В результате всех наших исследований и экспериментов нащ выбор пал на OpenStack.
Итак, что же это такое. По сути это набор сервисов для создания публичного или приватного облака.
Каждый сервис имеет API и выполняет свою конкретную задачу. Написаны все сервисы на Питоне.
Как я уже говорил это open-source продукт. Релизы случаются раз в полгода. В релиз входят базовые компоненты.
Каждый релиз включаются какие то новые компоненты. Так же есть инкубатор, где постоянно появляются новые компоненты.
Там они находятся какое то время, развиваются, потом сообщество принимает решение включать ли компонент в релиз или нет.
Roadmap у этого проекта публичный. Так же существуют различные maillists, митапы, конференции.
Самой крупной является Openstack Summit, проводится каждый год - на последнем было около 5000 посетителей.
У проекта очень много контрибьюторов, но я приведу лишь несколько из них, чтобы показать всю серьезность проекта.
Это RedHat, RackSpace, IBM, Intel, Cisco - этих имен достаточно чтобы понять, что проект жив и развивается.
Давайте посмотрим, как с помощью этого продукта мы решили свои проблемы.
Эффективная утилизация железа. В Openstack есть настраиваемый планировщик. Мы можем сказать ему по какому принципу выбирать хосты для деплоя виртуалок.
Так же есть так называемые Aggregation зоны. Куда мы можем выделить отдельные сервера, на которых будут деплоиться только определенные проекты.
Например, мы можем выделить отдельную зону для нагрузочного тестирования, чтобы оно не мешало другому окружению разработчиков.
Командные ресурсы. Теперь работа строится не по принципу "Хочешь вирталку - заведи тикет", а у команд есть свой набор ресурсов,
которыми они распоряжаются по своему усмотрению.
Модульность. Как я уже упоминал Openstack это набор сервисов, так что можно собрать себе необходимый набор.
Легко дорабатывать. Проект open source - можно патчить, писать свои компоненты (слава богу нам пока не приходилось)
API. Свои обвязки пишутся достаточно просто, так как каждый сервис имеет свой API и ко всем есть python биндинги.
Изоляция. Мы можем разделять людей по группам, сетям, как я уже упоминал - по aggregation зонам и т.д.
А что же конкретно после внедрения Openstack получили наши команды разработки?
Если говорить кратко, то получили они такую вещь, как инфраструктура по требованию или IAAS.
Как это выглядит?
Есть такие понятия как стек и шаблон.
Стек - это набор облачных ресурсов (машин, сетей и т.д.), объединенных в цельную структуру. Шаблон - описание этого стека.
В нашем случае это yaml файл. У нас есть git репозиторий, где мы храним все шаблоны. Они доступны для всех и любой может прислать pull request.
С помощью этих шаблонов любой член команды может сдеплоить себе нужную конфигурацию нужного ему продукта.
Либо есть отдельные шаблоны для создания просто виртуальных машин, которые можно развернуть и потестить деплой продуктов.
Вот так выглядит создание стеков из шаблонов с помощью CLI - мы передаем на вход наш шаблон плюс входные параметры, обозначенные в этом же шаблоне.
В шаблоне так же можно указать output - вернуть необходимую информацию, которую можно использовать в дальнейших шагах автоматизации.
Текущий статус Openstacka в компании такой:
Для отказоустойчивости Control Plane у нас расположена на трех hardwar`ных нодах вот с такими характеристиками.
Кастомерские виртуалки у нас крутятся на 8 компьют нодах с такими характеристиками. Которые в свою очередь поделены на 3 aggregation зоны:
одна для нагрузочного тестирования, вторая для внутреннего проекта vmmaster с помощью которого у нас тестируется UI под все браузеры,
и третья - самая большая, в которой расположены все остальные виртуалки (девелоперское окружение, тестовые стенды, ci сервера и т.д.)
Всего же у нас крутится порядка 350 виртуалок.
Какие уроки мы извлекли из этой истории.
Для деплоя и дальнейшего обслуживания Openstacka нужна команда. И команда нужна со следующими компетенциями:
- Ansible. Хороший уровень. Деплой Openstacka весь написан на нем.
- Virtualization. Опыт работы с KVM и LXC
- Network. Нужно понимать как она работает, уметь ее настроить и искать неисправности
- Gallera
- Rabbit MQ
- DNS
- Python. Нужно уметь понимать код, дебажить его, уметь при необходимости найти и применить нужные патчи
- Infrastructure as a Code. Все измения должны храниться в коде. Ничего нельзя делать руками
- Опыт работы с распределенными отказоустойчивыми системами
- Continuous Integration
Потому что это только верхнеуровнево все выглядит вот так красиво. При большей детализации все выглядит следующим образом.
Однако это не только техническое решение. Мы проводили работу с командами, так как продукт сложный, не всем сразу был понятен и не было сразу понятно
какой профит принесет это для команд. Так что при внедрении не надо забывать об обучении и стоит выделять время на такую активность как:
- Написание пользовательской документации. Различные quick start, faq, и т.д.
- Проведение techtalks. Где рассказывать как работать с продуктом, показывать демонстрации и т.д.
- Работа непосредственно в команде. Чтобы оперативно решать проблемы, например помогать реализовывать шаблоны и отвечать на вопросы.