В своей практике мы часто сталкиваемся с задачей адаптации клиентских приложений для запуска в 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, воркшопы и пообщаться в опенспейсах.
Мы собрали важные инсайты с шести выступлений и провели интервью с несколькими спикерами, чтобы узнать о том, что осталось за рамками докладов.
Внутри:
Прим. перев.: Service mesh — явление, которое ещё не имеет устойчивого перевода на русский язык (более 2 лет назад мы предлагали вариант «сетка для сервисов», а чуть позже некоторые коллеги стали активно продвигать сочетание «сервисное сито»). Постоянные разговоры об этой технологии привели к ситуации, в которой слишком тесно переплелись маркетинговая и техническая составляющие. Этот замечательный материал от одного из авторов оригинального термина призван внести ясность для инженеров и не только.
Комикс от Sebastian Caceres
Если вы инженер-программист, работающий где-то в районе бэкенд-систем, термин «service mesh», вероятно, уже прочно закрепился в вашем сознании за последние пару лет. Благодаря странному стечению обстоятельств, это словосочетание захватывает отрасль все сильнее, а хайп и связанные с ним рекламные предложения нарастают словно снежный ком, летящий вниз по склону и не подающий никаких признаков замедления.
Service mesh зародилась в мутных, тенденциозных водах экосистемы cloud native. К сожалению, это означает, что значительная часть связанной с ней полемики варьируется от «низкокалорийной болтовни» до — если воспользоваться техническим термином — откровенной чуши. Но если отсеять весь шум, можно обнаружить, что у service mesh есть вполне реальная, определенная и важная функция.
В этой публикации я попытаюсь проделать именно это: представить честное, глубокое, ориентированное на инженеров руководство по service mesh. Я собираюсь ответить не только на вопрос: «Что это такое?», — но и «Зачем?», а также «Почему именно сейчас?». Наконец, попытаюсь обрисовать, почему (по моему мнению) конкретно эта технология вызвала такой сумасшедший ажиотаж, что само по себе интересная история.Читать полностью »
В последнее время такие объявления заполонили интернет. Несмотря на приятную зарплату, не может не смущать, что внутри написана дикая ересь. Вначале предполагается, что «DevOps» и «инженер» можно каким-то образом склеить вместе в одно слово, а далее идет рандомный список требований, часть которых явно скопирована из вакансии сисадмина.
В этом посте хочется немного поговорить, как мы дошли до жизни такой, что такое DevOps на самом деле и что теперь с этим делать.
Такие вакансии можно всячески порицать, но факт остается фактом: их много, и так устроен рынок на данный момент. Мы сделали девопс-конференцию и открыто заявляем: «DevOops — не для DevOps-инженеров». Тут многим покажется странным и диким: почему люди, делающие совершенно коммерческое мероприятие, идут против рынка. Сейчас всё объясним.
Сегодня мы с огромной радостью представляем доклад Sysdig об использовании контейнеров за 2019 год (Sysdig 2019 Container Usage Report). Kubernetes продолжает набирать обороты, активнее осваиваются облачные архитектуры, и все это меняет не просто паттерны использования, но и процессы и организационные структуры. Удивительно, но в этом году двукратно увеличилось число контейнеров, срок жизни которых не превышает 5 минут. Чем динамичнее становятся сервисы, тем лучше облачные команды сознают необходимость интеграции безопасности в процессы DevOps. В рамках доклада об использовании за 2019 год мы впервые исследуем детали безопасности и соответствия — в дополнение к ряду деталей о том, как клиенты используют контейнеры, Kubernetes и проч.
9 декабря вышла очередная версия Kubernetes — 1.17. Ее девиз — «Стабильность», множество фич получили статус GA, некоторое количество устаревших фич было удалено…
И, как всегда, наш любимый раздел Action Required файла CHANGELOG-1.17.md требует к себе внимания.
Поработаем руками…
Читать полностью »
Вчера, 9 декабря, состоялся очередной релиз Kubernetes — 1.17. По сложившейся для нашего блога традиции, мы рассказываем о наиболее значимых изменениях в новой версии.
Информация, использованная для подготовки этого материала, взята из официального анонса, таблицы Kubernetes enhancements tracking, CHANGELOG-1.17 и соответствующих issues, pull requests, а также Kubernetes Enhancement Proposals (KEP). Итак, что нового?..Читать полностью »
