User
За окном классическая позитивная осенняя питерская погода, в конференц-зале Selectel тепло, кофе, кока-кола и почти лето. В окружающем мире 5 сентября 2019 года, у нас второй день от начала Слёрма DevOps.
В первый день интенсива мы прошли наиболее простые темы: Git, CI/CD. На второй день мы приготовили участникам Infrastructure as Code и тестирование инфраструктуры — темы многогранные, с большим количеством нюансов и практических заданий.
kubectl get pod вы получаете:Unable to connect to the server: x509: certificate has expired or is not yet valid
4 сентября в Санкт-Петербурге начался Слёрм DevOps.
В одном месте и в одном времени собрались все необходимые факторы для увлекательного интенсива длительностью в три дня: удобный конференц-зал Selectel, семь десятков любопытных разработчиков в зале и 32 участника в онлайне, сервера Selectel для практики. И зелёный динозавр, притаившийся в углу.
В первый день Слёрма перед участниками выступили три спикера.
Павел Селиванов, архитектор решений в Southbridge, занимается администрированием более 10 лет, является Certified Kubernetes Administrator. Постоянный спикер Слёрма. Делал доклады на конференциях Moscow Kubernetes Meetup и UWDC. Обладает богатым опытом внедрения Kubernetes: 5 проектов — индивидуальная работа, 20+ проектов в составе команды.
Артём Галонский, СТО «БюроБюро», специально прибыл на Слёрм DevOps из Калининграда. Опыт в коммерческой разработке более 12 лет. Выступал в роли тимлида\руководителя отдела разработки с 2011 года. Техническим директором стал в 2016 году. Считает, что devops-инженер — это что-то вроде единорога. Не в том смысле, что поймать его может только девственница. А в том, что никто не знает, что это такое на самом деле.
Алексей Степаненко, инженер отдела облачной платформы Selectel, занимается инфраструктурными задачами по обслуживанию облака OpenStack: мониторинг, CI/CD и управление конфигурациями.
TL;DR: может ли Haiku получить надлежащую поддержку пакетов приложений, к примеру каталогов приложений (как .app в Mac) и/или образов приложений (Linux AppImage)? Мне кажется, это будет достойным дополнением, которое правильно внедрить проще, чем в других системах, поскольку большая часть инфраструктуры уже есть.
У нас был долгий ненастный питерский вечер, конференц-зал Selectel на 70 мест, два десятка техдиров, более пятидесяти it-разработчиков разной степени небритости, несколько HR, мощнейший Дмитрий Симонов, 200 банок пива, 100 бутылок лимонада, несколько интересных тем, 6 спикеров, настроенная трансляция, 3.14 литра концентрированного хорошего настроения и даже одна неуловимая девушка-техдир. Не то, что это всё нужно было в Питере за день до Слёрм DevOps, но если начал организовывать мероприятия, то иди в своём увлечении до конца. Единственное, что нас беспокоило — это адрес ресторана KorovaBar, где мы коротали вечера во время февральского Слёрма. В мире нет ничего более увлеченного, игнорирующего физические препятствия и объективную реальность, общительного и громогласного, чем несколько CTO, собравшихся в одном месте в одно время рядом с гремучей смесью из пива, коллег и дискуссионных тем. Мы знали, что так или иначе окунёмся во всё это с головой.
Даниил Подольский, руководитель разработки в MTGroup, расскажет про выгорание айтишников, которое чревато потерей самых вовлеченных и ключевых сотрудников.
Кирилл Малеванов, технический директор Selectel, расскажет про инфраструктуру глазами провайдера.
Иван Михеев, Deputy CTO в AGIMA, покажет кейсы из своей практики: «Как потерять 3 руководителя и понять, что без них может быть лучше» и т. д.
Денис Ильиных, технический директор GT-Shop, расскажет про задачи техдира, решением которых занят.
Потрясающий выпуск GitLab 12.2 поможет командам оптимизировать пайплайны, расширить возможности совместной работы и управлять взаимозависимостями между проектами. Подробности ниже.
Пайплайны CI нужны для автоматизации задач сборки и тестирования, чтобы ускорить поставку ПО и избежать ошибок, присущих обработке вручную. Но в некоторых случаях эффективность пайплайнов GitLab CI/CD далека от идеала. GitLab 12.2 теперь поддерживает направленные ациклические графы (DAG), чтобы создавать зависимости детализированных заданий и управлять ими, а не полагаться на последовательные этапы. Это суперэффективный инструмент, с которым ваши пайплайны CI станут работать быстрее и продуктивнее.
TL;DR: Распечатка выглядит как привет из 90-х, Windows 3.x вызывает свои принтеры обратно. Сканирование удивительно "просто работает", по крайней мере при подключении USB. 3D печать в разработке. Поддержка сети вызывает смешанные чувства. Смартфоны у меня пока не заработали. Устройства с последовательным интерфейсом USB, в основном, работают.
Обновление!. В комментах один из читателей предложил попробовать Linstor (возможно, он сам над ним работает), так что я добавил раздел об этом решении. Еще я написал пост о том, как его установить, потому что процесс сильно отличается от остальных.
Если честно, я сдался и отказался от Kubernetes (во всяком случае, пока). Буду использовать Heroku. Почему? Из-за хранения! Кто бы мог подумать, что я буду больше возиться с хранилищами, чем с самим Kubernetes. Я использую Hetzner Cloud, потому что это недорого и производительность хорошая, и с самого начала я развертывал кластеры с помощью Rancher. Я не пробовал управляемые сервисы Kubernetes от Google/Amazon/Microsoft/DigitalOcean и проч., проч., потому что всему хотел научиться сам. А еще я экономный.
TL;DR: Haiku — операционная система, специально разработанная для ПК, поэтому у нее есть несколько хитростей, делающих ее рабочее окружение намного лучше других. Но как оно работает?
Когда в Linux сервер базы данных непредвиденно завершает работу, нужно найти причину. Причин может быть несколько. Например, SIGSEGV — сбой из-за бага в бэкенд-сервере. Но это редкость. Чаще всего просто заканчивается пространство на диске или память. Если закончилось пространство на диске, выход один — освободить место и перезапустить базу данных.
Когда у сервера или процесса заканчивается память, Linux предлагает 2 пути решения: обрушить всю систему или завершить процесс (приложение), который съедает память. Лучше, конечно, завершить процесс и спасти ОС от аварийного завершения. В двух словах, Out-Of-Memory Killer — это процесс, который завершает приложение, чтобы спасти ядро от сбоя. Он жертвует приложением, чтобы сохранить работу ОС. Давайте сначала обсудим, как работает OOM и как его контролировать, а потом посмотрим, как OOM Killer решает, какое приложение завершить.
Авторы: Тед Янг, Притам Шах и «Комитет технических спецификаций» (Карлос Альберто, Богдан Друту, Сергей Канжелев и Юрий Шкуро).
Совместный проект обзавелся названием: http://opentelemetry.io
TL;DR: Новичок увидел Haiku в первый раз, пробует портировать некоторые программы из мира Linux.
Сегодня в Southbridge на планерке обсуждали бирюзовый менеджмент.
Были те, кто предлагал двигаться сверху вниз, от идеи к практике. Мол, давайте внедрим философию бирюзового менеджмента: найдем эталон, примем решение о том, как должны делиться роли, как должна строиться коммуникация, и начнем двигаться в этом пути.
Были те (и я в том числе), кто хотел двигаться снизу вверх, от практики к идее. У нас есть конкретные задачи и конкретные проблемы. Давайте решать их, опираясь на бирюзовые инструменты, и бирюзовый менеджмент сложится сам собой.
Если сравнивать управление с разработкой, то путь сверху вниз — это создание монолита, а путь снизу вверх — это микросервисная архитектура. Сейчас, в нашем «микросервисном» управлении, мы можем два раза в день перестроить управленческий контур и немедленно «выкатить его в продакшен».
И программа Слёрм DevOps создана для тех, кто предпочитает двигаться снизу вверх.
Kubectl — это эффективный инструмент командной строки Kubernetes и для Kubernetes, пользуемся мы им ежедневно. У него много функций, и с ним можно развертывать систему Kubernetes или его базовые фичи.
Вот вам полезные советы, как быстрее кодить и деплоить в Kubernetes.
TL;DR: спустя несколько дней экспериментов с Haiku я решил поставить ее на отдельный SSD. Но все оказалось не так-то непросто.
4-6 сентября в Санкт-Петербурге, в конференц-зале Selectel пройдет трехдневный Слёрм DevOps.
Мы строили программу, исходя из мысли, что теоретические труды по DevOps, как и мануалы к инструментам, каждый может прочитать самостоятельно. Интересны только опыт и практика: объяснение, как делать надо и не надо, и рассказ, как делаем мы.
В каждой компании, у каждого администратора или разработчика свой уровень DevOps. Одни неправильно используют Git, другие внедряют SRE. Курс организован так, чтобы каждый нашел что-то актуальное, что можно внедрить здесь и сейчас.
Мы начинаем с Git, потом смотрим на разработку приложения, взаимодействие кода и инфраструктуры, строим CI/CD, описываем инфраструктуру как код (IaC), тестируем получившееся решение, настраиваем мониторинг, собираем и изучаем логи, и в конце доходим до SRE: превращаем надежность в измеряемую и управляемую историю.
TL;DR: Haiku может стать великолепной настольной операционной системой с открытым исходным кодом. Мне правда этого хочется, но требуется еще много исправлений.
Чем быстрее процесс разработки, тем быстрее развивается технологическая компания.
К сожалению, современные приложения работают против нас — наши системы должны обновляться в режиме реального времени и при этом никому не мешать и не приводить к простоям и перерывам. Развертывание в таких системах становится сложной задачей и требует сложных пайплайнов непрерывной поставки даже в маленьких командах.
Эти пайплайны обычно имеют узкое применение, медленно работают и не отличаются надежностью. Разработчики должны сначала создать их вручную, а потом управлять ими, и компании часто нанимают для этого целые команды DevOps.
От скорости этих пайплайнов зависит скорость разработки. У лучших команд развертывание занимает 5–10 минут, но обычно все делается гораздо дольше, и для одного развертывания требуется несколько часов.
TL;DR: я восхищен Haiku, но доработать есть что
Вчера я изучал Haiku — операционную систему, которая меня приятно удивила. День второй. Поймите правильно: я все еще восхищен тем, насколько легко она делает то, что тяжело дается на рабочих окружениях для Linux. Горю желанием узнать, как она работает, а также полон энтузиазма использовать ее ежедневно. Правда, день для полного перехода еще не наступил: страдать не хочется.