Ну вот эти обычные для "экзотического" стека. Я потрачу силы и время на этот опыт, а потом не буду нужен рынку, потому-что рынок больше хочет разработчиков на языке Н. А иногда и на конкретном фреймворке.
Devops — это идея, из которой вышел некоторый набор практик.
Это точно не отдельный человек и не роль. Отдельные люди, которых скорее всего и ищут — это:
Билд\релиз инженер — человек, который отвечает за сервисы сборки, релиза, деплоя, помогает выстроить процесс сбора обратной связи.
Инженер инфраструктурных сервисов — человек, который строит удобное внутреннее\внешнее облако для запуска сервисов. Это он делает мониторинг aaS, базу aaS, сбор трейсинг-спанов aaS, что-то ещё aaS.
Инженер по надёжности систем — человек, который радеет за то, что сервис будет работать, редко падать и быстро чиниться. Это он учит людей правильным архитектурным паттернам.
Эти роли могут быть распределены внутри команды разработки, а могут исполняться отдельными командами.
P.S. Системный администратор — это администратор какой-то\каких-то систем. Это нормально — называть сисадминами людей, один из которых рулит флотом серверов на амазоне, а второй отвечает за работоспособность двух серверов 1С-Бухгалтерия и локальной сети. Должности одинаковы, системы (а скорее всего и уровни ответственности\оплаты) — разные.
Так эти хранилища решают другие проблемы:
Аудит
Настраиваемая гибкость доступа к секретам
Обслуживание жизненного цикла секретов и доступов
Безопасность — это вообще сложная тема, тут нет серебряных пуль, которые сделают вашу систему безопасной. Только работа с рисками, только хардкор :)
Я не понимаю, как ваши слова противоречат статье и паттерну использования Vault.
Vault не запрещает гибко управлять доступами к секретам. Общность секретов — только в расположении secret/infra/whatever.
Вы можете и должны делать токены для доступа только к тем секретам, которые необходимы и достаточны для выполнения работ.
Например у вас есть сервис, который использует все секреты из secret/service_name и только jenkins_api_token из инфраструктурных секретов.
Вы понимаете, что смысл этой статьи сводится к
1) А вот есть Jenkins
2) А вот Jenkins умеет пуллить изменения в гите
3) А вот можно затолкать скрипт в дженкинс — и это будет работать
?
Ну вот например настройка лоад-балансера в container-engine — https://cloud.google.com/container-engine/docs/tutorials/http-balancer.
Нет здесь сценария
То есть вы отдаете свой контейнер, в котором запакован ваш код, в какое-то мифическое облако, а оно самостоятельно по очереди выключает воркеры из балансера, запускает новые контейнеры и добавляет их в балансер. Сами контейнеры находят внешние сервисы, которые обслуживают стейт(базы, кэша, whatever) и подключают приложения к этим базам.
Если лично вы не занимались настройкой этого облака под свои нужды — значит это было сделано до вас. Но было. Чудес не бывает. Были бы чудеса — мы бы могли избавиться от наших девопс и опс команд, которые обслуживают _тысячи_ хостов на AWS. Решая все те проблемы, которые, по вашему, из-коробки решаются с помощью докера. Удачи вам в вашем мире. Я пожалуй исключусь из дискуссии.
Я вас к тому и веду. ВНЕЗАПНО выясняется, что для того, чтобы облако это умело — системным инженерам нужно позаботиться о паре _небольших_ вещей. Сервис дискавери, распределенные конфиги, автоматика переключения, автоматика деплоя, работа с лоад балансером, очередями. Репликация, бэкапы, отказоустойчивость на уровне датацентров.
Мне кажется, что это совсем _немного_ выходит за рамки заявленного «Отдать контейнер в облако и оно там все само», но все-таки выходит. Я вас по-прежнему не переубедил?
Действительно высоконагруженые сервисы без облака нынче не мыслимы…
Если вы внимательно прочитаете мой коммент — вы не найдете противоречий со своим.
А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.
С чего вы это взяли? Бред же… Это уже давно стандарт ;)
То есть вы отдаете свой контейнер, в котором запакован ваш код, в какое-то мифическое облако, а оно самостоятельно по очереди выключает воркеры из балансера, запускает новые контейнеры и добавляет их в балансер. Сами контейнеры находят внешние сервисы, которые обслуживают стейт(базы, кэша, whatever) и подключают приложения к этим базам.
Я все правильно понимаю?
По-прежнему не понимаю, как у вас контейнеризация позволяет быстро менять железные хосты под бд. Но предположу.
Сами файлы находятся на внешнем сторадже, который монтируется в сервер и куда смотрит контейнер с субд. При падении сервера, этот же сторадж монтируется в другой сервер, где поднимается такой же контейнер — и все работает.
Если мое предположение верно — то ключом к успеху тут является внешний сторадж, а не контейнер.
Если я ошибаюсь — то поясните пожалуйста, интересно.
Два кейса из тестовой инфраструктуры:
Кейз один — приложение по-умолчанию запускается на всех физических ядрах, которое находит. Приложение тестируется на машинах с 8 ядрами, у разработчиков тоже всегда 8 ядер или меньше. Новый сервер, 32 ядра — приложение ведет себя не стабильно или не так, как ожидалось(оставим за скобками код, который так работает). Хотя казалось бы тот же образ, тот же код, тот же контейнер.
Кейз два — приложение всегда работало, не зная про ipv6. Докер работал на ядре, в котором этот механизм был отключен. Новое железо, про эту особенность никто не думал, ipv6 по-умолчанию включен. Сталкиваемся с проблемой резолвинга локалхоста — сначала резолвится ipv6 адрес, который приложение обрабатывать не умеет. А в Докере кстати нельзя убрать ipv6 адрес локалхоста из /etc/hosts, без грязных трюков и он там присутствует даже если у вас в sysctl стоит опция ipv6 all disable и в самом докере вы сказали --ipv6=False. Помогает только отключение на уровня ядра, при загрузке.
Я понимаю, что никто. Везде trade-off. Я вообще докер не ругаю, я его люблю с версии 0.5 или 0.6.
Но идеализировать технологию и все пихать в нее — это как-то странно. Всегда важно четко понимать, зачем тащить любую технологию в продакшн.
Тот, кто отвечает за работу приложения в продуктивной среде.
Как эта роль называется в конкретной компании\команде — не суть важно.
Плох тот разработчик, который считает, что его дело — код писать, а как он дальше работает — не его забота.
Также плох и тот админ, который считает разработчиков идиотами и не в силах настроить коммуникацию с ними так, чтобы требования и нужды эксплуатации принимались во внимание.
Ну ладно вам :) Эт специфика таких вот маркетинговых публикаций. Так-то эт реально интервью было, просто попросили выложить под собой.
Я вроде такого не говорил. Базовый принцип - да, дублируй всё, что можешь. Дальше начинаются нюансы.
Ну вот эти обычные для "экзотического" стека. Я потрачу силы и время на этот опыт, а потом не буду нужен рынку, потому-что рынок больше хочет разработчиков на языке Н. А иногда и на конкретном фреймворке.
А как вы работаете с возражениями разработчиков ДО этапа онбординга?
А вы вживую ходили или в записи смотрели?
Devops — это идея, из которой вышел некоторый набор практик.
Это точно не отдельный человек и не роль. Отдельные люди, которых скорее всего и ищут — это:
Эти роли могут быть распределены внутри команды разработки, а могут исполняться отдельными командами.
P.S. Системный администратор — это администратор какой-то\каких-то систем. Это нормально — называть сисадминами людей, один из которых рулит флотом серверов на амазоне, а второй отвечает за работоспособность двух серверов 1С-Бухгалтерия и локальной сети. Должности одинаковы, системы (а скорее всего и уровни ответственности\оплаты) — разные.
Cabin уже умер, btw.
Так мы не от админа с рут-доступом защищаемся. Мы защищаемся от некоего злоумышленника, который мог получить доступ к хранилищу.
Можно построить, только без веб-gui.
Так эти хранилища решают другие проблемы:
Аудит
Настраиваемая гибкость доступа к секретам
Обслуживание жизненного цикла секретов и доступов
Безопасность — это вообще сложная тема, тут нет серебряных пуль, которые сделают вашу систему безопасной. Только работа с рисками, только хардкор :)
Я не понимаю, как ваши слова противоречат статье и паттерну использования Vault.
Vault не запрещает гибко управлять доступами к секретам. Общность секретов — только в расположении secret/infra/whatever.
Вы можете и должны делать токены для доступа только к тем секретам, которые необходимы и достаточны для выполнения работ.
Например у вас есть сервис, который использует все секреты из secret/service_name и только jenkins_api_token из инфраструктурных секретов.
Вы можете сделать политику
И выдать токен, ограниченный только теми доступами, которые вам нужны.
Астрологи объявили неделю Ansible.
Количество постов про ansible увеличилось втрое.
Вы понимаете, что смысл этой статьи сводится к
1) А вот есть Jenkins
2) А вот Jenkins умеет пуллить изменения в гите
3) А вот можно затолкать скрипт в дженкинс — и это будет работать
?
Это о чем?
Нет здесь сценария
Если лично вы не занимались настройкой этого облака под свои нужды — значит это было сделано до вас. Но было. Чудес не бывает. Были бы чудеса — мы бы могли избавиться от наших девопс и опс команд, которые обслуживают _тысячи_ хостов на AWS. Решая все те проблемы, которые, по вашему, из-коробки решаются с помощью докера. Удачи вам в вашем мире. Я пожалуй исключусь из дискуссии.
Мне кажется, что это совсем _немного_ выходит за рамки заявленного «Отдать контейнер в облако и оно там все само», но все-таки выходит. Я вас по-прежнему не переубедил?
Можете подсказать название этого облака?
Если вы внимательно прочитаете мой коммент — вы не найдете противоречий со своим.
То есть вы отдаете свой контейнер, в котором запакован ваш код, в какое-то мифическое облако, а оно самостоятельно по очереди выключает воркеры из балансера, запускает новые контейнеры и добавляет их в балансер. Сами контейнеры находят внешние сервисы, которые обслуживают стейт(базы, кэша, whatever) и подключают приложения к этим базам.
Я все правильно понимаю?
Сами файлы находятся на внешнем сторадже, который монтируется в сервер и куда смотрит контейнер с субд. При падении сервера, этот же сторадж монтируется в другой сервер, где поднимается такой же контейнер — и все работает.
Если мое предположение верно — то ключом к успеху тут является внешний сторадж, а не контейнер.
Если я ошибаюсь — то поясните пожалуйста, интересно.
Два кейса из тестовой инфраструктуры:
Кейз один — приложение по-умолчанию запускается на всех физических ядрах, которое находит. Приложение тестируется на машинах с 8 ядрами, у разработчиков тоже всегда 8 ядер или меньше. Новый сервер, 32 ядра — приложение ведет себя не стабильно или не так, как ожидалось(оставим за скобками код, который так работает). Хотя казалось бы тот же образ, тот же код, тот же контейнер.
Кейз два — приложение всегда работало, не зная про ipv6. Докер работал на ядре, в котором этот механизм был отключен. Новое железо, про эту особенность никто не думал, ipv6 по-умолчанию включен. Сталкиваемся с проблемой резолвинга локалхоста — сначала резолвится ipv6 адрес, который приложение обрабатывать не умеет. А в Докере кстати нельзя убрать ipv6 адрес локалхоста из /etc/hosts, без грязных трюков и он там присутствует даже если у вас в sysctl стоит опция ipv6 all disable и в самом докере вы сказали --ipv6=False. Помогает только отключение на уровня ядра, при загрузке.
Я понимаю, что никто. Везде trade-off. Я вообще докер не ругаю, я его люблю с версии 0.5 или 0.6.
Но идеализировать технологию и все пихать в нее — это как-то странно. Всегда важно четко понимать, зачем тащить любую технологию в продакшн.
Как эта роль называется в конкретной компании\команде — не суть важно.
Плох тот разработчик, который считает, что его дело — код писать, а как он дальше работает — не его забота.
Также плох и тот админ, который считает разработчиков идиотами и не в силах настроить коммуникацию с ними так, чтобы требования и нужды эксплуатации принимались во внимание.