На Хабре много статей о Jenkins, но мало где описывается пример работы Jenkins и докер агентов. Все популярные инструменты сборки проектов типа Drone.io, Bitbucket Pipeline, GitLab, GitHub actions и другие, могут собирать все в контейнерах. Но как же Jenkins?
На сегодняшний день есть решение проблемы: Jenkins 2 замечательно умеет работать с Docker агентами. В статье я хочу поделиться опытом и показать, как вы можете это сделать сами.
В данной статье я хочу поделиться с вами способом создания SSL сертификата для вашего веб-приложения работающего на Docker, т.к. в рускоязычной части интернета — подобного решения я не нашел.
Подробнее под катом.
Читать полностью »
Реальность сетевого инженера (с лапшой и… солью?)
В последнее время, обсуждая с инженерами разные инциденты, я заметил интересную закономерность.
В этих обсуждениях неизменно возникает вопрос «первопричины». Верные читатели наверняка знают, что у меня есть несколько мыслей по этому поводу. Во многих организациях анализ инцидентов полностью основан на этой концепции. Они используют разные техники выявления причинно-следственных связей, такие как «Пять почему». Эти методы предполагают так называемую «линейность событий» как неоспоримую догму.
Когда вы подвергаете сомнению эту идею и указываете на то, что в сложных системах линейность успокаивающе обманчива, то рождается увлекательная дискуссия. Спорщики страстно настаивают, что только знание «первопричины» позволяет понять происходящее.
Я заметил интересную закономерность: разработчики и девопсы по-разному реагируют на эту идею. По моему опыту, разработчики чаще утверждают, что первопричина имеет значение и что в событиях всегда можно установить причинно-следственные связи. С другой стороны, девопсы чаще соглашаются, что сложный мир не всегда подчиняется линейности.
Читать полностью »
Изображение: Unsplash
Всем привет! Мы инженеры-автоматизаторы из компании Positive Technologies и занимаемся сопровождением разработки продуктов компании: поддерживаем весь сборочный конвейер от коммита строчки кода разработчиками до публикации готовых продуктов и лицензий на серверах обновлений. Неформально нас называют DevOps-инженеры. В этой статье мы хотим рассказать про технологические этапы процесса производства ПО, про то, как мы их видим и как классифицируем.
Из материала вы узнаете про сложность координации мультипродуктовой разработки, про то, что такое технологическая карта и как она помогает упорядочивать и тиражировать решения, из каких основных этапов и шагов состоит процесс разработки, как разграничены зоны ответственности между DevOps и командами в нашей компании.Читать полностью »
Мы давно пользуемся облачными сервисами: почта, хранилища, соцсети, мессенджеры. Все они работают удаленно — отправляем сообщения и файлы, а хранятся и обрабатываются они на удаленных серверах. Также работает и облачный гейминг: пользователь подключается к сервису, выбирает игру и запускает. Для игрока это удобно, потому что игры запускаются почти мгновенно, не занимают память, и не нужен мощный игровой компьютер.
Для облачного сервиса все иначе — у него возникают проблемы хранения данных. Каждая игра может весить десятки или сотни гигабайт, например, «Ведьмак 3» занимает 50 Гбайт, а «Call of Duty: Black Ops III» — 113. При этом игроки не будут пользоваться сервисом с 2-3 играми, как минимум нужно несколько десятков. Кроме хранения сотен игр, сервису нужно решать, какой объем хранилища выделять на одного игрока, и масштабироваться, когда их будут тысячи.
Хранить ли все это на своих серверах: сколько их нужно, где ставить дата-центры, как «на лету» синхронизировать данные между несколькими дата-центрами? Покупать «облака»? Использовать виртуальные машины? Можно ли хранить данные пользователей со сжатием в 5 раз и предоставлять их в real-time? Как исключить любое влияние пользователей друг на друга при последовательном использовании одной и той же виртуальной машины?
Все эти задачи успешно удалось решить в Playkey.net — облачной игровой платформе. Владимир Рябов — руководитель отдела системного администрирования — подробно расскажет о технологии ZFS для FreeBSD, которая в этом помогла, и ее свежем форке ZOL (ZFS on Linux).
Читать полностью »
В своей практике мы часто сталкиваемся с задачей адаптации клиентских приложений для запуска в Kubernetes. При проведении данных работ возникает ряд типовых проблем. Одну из них мы недавно осветили в статье Локальные файлы при переносе приложения в Kubernetes, а о другой, связанной уже с процессами CI/CD, — расскажем в этом материале.Читать полностью »
Расшифровка:
Азат Хадиев: Здравствуйте. Меня зовут Азат Хадиев. Я разработчик PaaS направления Mail.ru Cloud Solutions. Со мной здесь Павел Селиванов из компании Southbridge. Мы находится на конференции DevOpsDays. Он здесь выступит с докладом о том, что с Kubernetes можно построить DevOps, но скорее всего у вас ничего не получится. Почему такая мрачная тема?
Читать полностью »
Мир сходит с ума, заталкивая калькулятор для 2+2 в облака. Чем мы хуже? Давайте Hello World затолкаем в три микросервиса, напишем пару-тройку тестов, обеспечим пользователей документацией, нарисуем красивый пайплайн сборки и обеспечим деплой в условный облачный прод при успешном прохождении тестов. Итак, в данной статье будет показан пример того, как может быть построен процесс разработки продукта от спецификации до деплоя в прод. Инетересно? тогда прошу под катЧитать полностью »
У вебинара плохой звук, поэтому мы сделали расшифровку.
Меня зовут Медведев Эдуард. Я сегодня поговорю о том, что такое SRE, как появилось SRE, какие есть критерии работы у SRE-инженеров, немножко о критериях надежности, немножко о ее мониторинге. Мы пройдемся по верхам, потому что за час много не расскажешь, но я дам материалы для дополнительного ознакомления, и мы все ждем вас на Слёрме SRE. в Москве в конце января.
7 декабря прошла третья конференция DevOpsDays Moscow, организованная московским DevOps-сообществом при поддержке Mail.ru Cloud Solutions. Кроме докладов ведущих практиков DevOps, участники могли посетить короткие мотивирующие Lightning Talks, воркшопы и пообщаться в опенспейсах.
Мы собрали важные инсайты с шести выступлений и провели интервью с несколькими спикерами, чтобы узнать о том, что осталось за рамками докладов.
Внутри:
