Devops Bootcamp с Федосеевым

📎Когда Terraform план уже всё сказал, а ты всё равно идёшь дальше, потому что “ну там, наверное, не критично”

⏩Когда Terraform план уже всё сказал, а ты всё равно идёшь дальше, потому что “ну там, наверное, не критично”

История работ на Gitlab. Часть 2💬 Мы остановились на проблеме с SSH‑доступом. Часть пользователей неожиданно перестала подключаться по SSH: • Ключи в UI GitLab были видны, как добавленные. • При попытке клонирования или git fetch GitLab запрашивал пароль или возвращал ошибку «Permission denied (publickey)». 🔴В чем суть • Когда Sidekiq был на том же сервере, он читал /var/opt/gitlab/.ssh/authorized_keys и было нормально. • Когда мы вынесли его, он начал писать в свой /var/opt/gitlab/.ssh/authorized_keys на ноде сайдкика. Произошла потеря мапинга ключа и прав пользователя, которая через БД. Помог ребилд этого файла из БД gitlab-rake gitlab:shell:setup. Но при добавлении или изменении ключа он писал новую инфу снова на ноду сайдкика. И так по кругу. Решили проблему вот так. А теперь финальное, сломалось покрытие кода. Просто перестал работать данный функционал. Для code coverage Sidekiq парсит job.log в рилтайме, но процесс лога джобы такой, что он пумой кладётся на ФС гитлаба в одно место во время джобы (и тут он ещё не артефакт). А по завершению запаковывается уже в артефакт в другое место, по флоу в ссылке. И раньше сайдкик нормально парсил этот job.log в директории, а после выноса он перестал видеть ФС на основной ноде и не парсил ничего, но при этом опять же все артефакты заданий в UI и S3 были. ⏩В итоге включили инкрементальное логирование. Теперь логи шлются в Redis, а не во временный файл на ФС. Redis виден Sidekiq и он может парсить логи для поиска и отображения процентов в интерфейсе. Из плюсов, логи теперь вобще не пишутся на ФС, а из минусов, эта схема не работает с кластерным Redis. Какая мораль Вынос Sidekiq на отдельный сервер – шаг вполне стандартный и рекомендованный для масштабирования GitLab. Документация хорошая, но иногда совсем не ясно где искать необходимое. При этом, он обнажает любые неаккуратности в конфигурации и особенности архитектуры.

Приветы! На связи Аниса 🤓 Легендарные долгожданные майские начались! Включаем режим качественного отдыха и перенимаем Правила жизни моего уважаемого альфа-кота Сырка (фото прилагаю в обязательном порядке): Правило 1: Сон — наш союзник

Для современного кота и человека очень важно перезагружаться. Выходной — прекрасная возможность успокоиться и позволить себе вздремнуть после прогулки 😴

Правило 2: Любопытство — путь к развитию

Будь то исследование картонной коробки или истории возникновения египетских пирамид — всё это добавляет интереса к жизни и позволяет сохранить себя в роли не только работника, но и человека, самого себя.

Правило 3: Здоровый эгоизм — необходимая часть личности

Не нравится, как гладят — уходим в домик, а если чувствуем перегруз в работе — говорим «нет» новым задачам или предлагаем двигать приоритет текущих (об этом, кстати, был пост). Быть хорошим для всех равнозначно потере самого себя.

Как считаете, база? Обязательно делитесь фотками и мудростями своих пушистых домочадцев в комментариях — часто они и правда делают нас лучше)

Приветы! На связи Аниса 🤓 Легендарные долгожданные майские начались! Включаем режим качественного отдыха и перенимаем Правила жизни моего уважаемого альфа-кота Сырка (фото прилагаю в обязательном порядке): Правило 1: Сон — наш союзник

Для современного кота и человека очень важно перезагружаться. Выходной — прекрасная возможность успокоиться и позволить себе вздремнуть после прогулки 😴

Правило 2: Любопытство — путь к развитию

Будь то исследование картонной коробки или истории возникновения египетских пирамид — всё это добавляет интереса к жизни и позволяет сохранить себя в роли не только работника, но и человека, самого себя.

Правило 3: Здоровый эгоизм — необходимая часть личности

Не нравится, как гладят — уходим в домик, а если чувствуем перегруз в работе — говорим «нет» новым задачам или предлагаем двигать приоритет текущих (об этом, кстати, был пост). Быть хорошим для всех равнозначно потере самого себя.

Как считаете, база? Обязательно делитесь фотками и мудростями своих пушистых домочадцев в комментариях — часто они и правда делают нас лучше)

Коллеги, приветствую👋 Рад сообщить, что Слёрм анонсировал новый курс: Интенсив по погружению в GIT Как проходит обучение: ➡️10 дней практики по 2–3 часа в день ➡️Видеоуроки + текстовые гайды ➡️Разбор заданий от эксперта ➡️Командный проект с ретроспективой и проектом в портфолио ⏩Автор и спикер курса: Кирилл Казарин, менеджер глобальных направлений DevOps/SRE в RingCentral Inc. Стаж в администрировании — 15 лет. ⏩Старт: 20 мая ⏩ ПОЛУЧИТЬ НОВЫЕ ЗНАНИЯ

История работ на Gitlab. Часть 1💬 Друзья, всем привет! Сегодня расскажу одну историю из моей практики. Однажды перед нами встала довольно понятная задача: в связи с ростом нагрузки и горизонтальным масшатбированием инстанса потребовалось вынести Sidekiq на отдельный хост. 🔴Схема была такой: делаем основной хост с API и всем тем, что осталось и новый отдельный хост под Sidekiq. Мы проверили, что у Sidekiq есть необходимый сетевой доступ, на основном GitLab‑узле Sidekiq отключили, а на новом сервере включили. Итог: все основные тесты прошли успешно. Стандартные фоновые задачи работали нормально. Пайплайны запускались, джобы отрабатывали без явных ошибок. А вот с динамическими пайплайнами возникла проблема, они не могли найти артефакты. ⏩Как это выглядело Джоба, которая должна была читать артефакты предыдущего стейджа, падала с ошибкой о том, что артефакты не найдены. Но при этом: • В UI GitLab артефакт у предыдущей джобы был, его можно было скачать руками. • Логи runner’а показывали стандартный запрос за артефактами, а затем падение на стороне GitLab. Ошибка проявлялась именно в сценариях с динамической генерацией. Ну как ошибка...даже не ошибка

  "exception.class": "Gitlab::Ci::Artifacts::DecompressedArtifactSizeValidator::FileDecompressionError",
  "exception.message": "File decompression error",

Чем-то похожие проблемы нашлись тут и тут. Если логически предположить, что теперь он ищет артефакты не там, значит выносим все артефакты, чтобы условия были единые. Для этого унесем их в S3, так как его можно использовать для хранения разных объектов. НО на тот момент артефакты всё ещё лежали на локальном диске. После вынесения Sidekiq эта схема стала особенно хрупкой. 🔴В итоге • Унесли все CI‑артефакты в S3‑совместимое object storage • Привели конфигурацию к единой схеме хранения, чтобы и web, и Sidekiq работали только через объектное хранилище. • Динамические пайплайны перестали падать, GitLab стабильно находил объекты, а Sidekiq корректно обрабатывал джобы, завязанные на артефакты. Все, можно применять на проде? Как бы не так. Новая проблема – сломавшиеся GitLab Pages ❌ Как только мы пофиксили одну проблему, вылезла следующая. Пользователи начали жаловаться, что GitLab Pages перестали открываться, часть проектов стала отдавать 404, а новые деплои страниц как будто вообще не происходили. То есть: • В репозиториях джобы pages отрабатывали успешно. • В файловой системе на стороне GitLab мы видели новые сборки в директории, которая служит storage для Pages • При обращении к GitLab Pages через домен выдавался 404, пока не перезапускали gitlab-pages. В нашем случае наложились сразу несколько факторов. И пути хранения перенастроенные (после ухода в object storage артефактов), и отдельный сервер Sidekiq, который обрабатывает джобы, отвечающие за публикацию Pages. ⏩В результате, gitlab-rails и Sidekiq думали, что Pages задеплоены на s3, складывали контент в нужное место, но сам Pages искал pages_deployments на файловой системе. Прям как тут. Решение вроде бы простое:

gitlab_rails['object_store']['objects']['pages']['bucket'] = 'gitlab-pages'

• Проверяем, что все пути совпадают и перезапускаем сервис. • Видим, что Pages вернулись к жизни и начали стабильно подхватывать новые деплои без ручных перезапусков. 🔴Но тестирование снова не проходит. Теперь у пользователей не находятся SSH ключи. Это последний неприятный эффект, который мы получили «бонусом» после всех изменений. Но о нем в следующей части)

Приветы! На связи Аниса 👸 Замечаю много обсуждений на рынке труда по следующему вопросу: Существует ли черный список кандидатов? Отвечаю серьезно с серьезным лицом по серьезной теме. Нет. Никакого черного списка кандидатов среди компаний и их HR не существует. Да, у Роструда с 2025 года есть реестр недобросовестных работодателей, нарушивших ТК РФ, что подтверждено в суде. Но речь здесь именно про компании. На мой взгляд, создание черного списка кандидатов провоцирует занесение компаниями в этот список своих топовых сотрудников, чтобы их не хантили. Лютый стонкс! ↗️ А также много субъективности и нездорового перекоса в карьерных взаимоотношениях между компанией и кандидатом. Какие ещё мифы/факты вы встречали? Пишите в комментариях — будем вместе разбираться, что есть что)

Коллеги, всем привет 👋🏻 💬 Сегодня захотелось просто поделиться историей. На прошлой неделе были всей командой в командировке, это по-своему классно. Благо еще нам повезло с погодой (на тот момент). Удалось обсудить планы по задачам на ближайшее время, теперь всем есть чем заняться. Но самое интересное, конечно же, не про работу. Мне только пришли оставшиеся детали на велосипед, и я все по нему доделал, как сразу подошло время забирать мотоцикл с хранения. И я даже нашел время это сделать, но теперь погода испортилась и пока не выходит привести мот в порядок. Чуть попозже расскажу вам, что за мотик будет в этом сезоне, и как я придумал печатать детали для него (только пока никак не получается это сделать красиво) 🔥 ⏩Делитесь, как ваши дела с наступлением теплого сезона?

Для тех, кто сомневался в ответе или дал неверный вариант, рекомендую к изучению курс ➡️ Основы работы с Docker За курс вы: ➖ Напишете правильный файл (Dockerfile) с первого раза ➖ Научитесь искать и исправлять ошибки (debug) в падающих контейнерах за минуту ➖ Поднимете среду, где размещён и работает ИТ-продукт, доступный конечным пользователям (production-окружение) через инструмент композиции контейнеров Docker (Docker Compose) 80% времени — практика в терминале на готовых стендах 📌Узнать подробнее про курс - по ссылке

Всем привет! На связи Аниса 🤓 Сегодня о священном — о ✨выходных✨, а именно: Как максимально отдохнуть в выходные законно без чувства усталости в понедельник 🔵Суббота — залипание в соцсетях, доделывание рабочих задачек, фильм, поздний отход ко сну. 🟣Воскресенье — поздной подъем, уборка (вдруг 😁), желание залечь дома на весь день и не двигаться. 🔴Понедельник — «как быстро прошли выходные!». И будто отдыха не было, хотя и занятости особо тоже. Говорю четко и уверенно: было! Признаюсь, я пробовала разные способы и вывела классную формулу: в выходные делать максимально противоположное своей работе. Ниже подробнее. 1. Сменить тип нагрузки Мозгу не нужен абсолютный покой — ему нужно переключение. Особенно, если все будние дни связаны с ноутбуком. ⚪️Работа руками: пазлы, лего, рисование или даже «потрогать траву» — одобряем. ⚪️Движение тела: прогулка (без подкастов, на улице красиво поют птицы, послушайте), плавание, спорт (необязательно качалка). ⚪️Отдых без экранов: настолки, живое общение, сон. Кстати, спать днем не стыдно!) 2. Отказаться от псевдоотдыха Скроллинг, залипание в ютубе на весь день или постоянное фоновое прослушивание подкастов — это literally дофаминовый долг! 🙅‍♂️ После них будет опустошение. Замените на что-то вдумчивое: фильм (целиком), книга, тишина и тд. 3. Остановить (попытаться) мысли о грядущем рабочем дне Во-первых — за это не платят 😎 Во-вторых — затрачивается колоссальный мыслительный ресурс на постоянное удерживание рабочих мыслей. Как вариант: записывать незакрытые задачи на бумагу и договориться с собой, мол «вернусь в понедельник». Уведомления выключить. Это нестрашно во второй раз, а в первый раз нужно продержаться))

Говорю честно: эти практики достаточно сложно даются в первые разы. Логично, ведь соцсети и вынужденная многозадачность воспитали в нас неутолимый дофаминовый голод. Однако, согласитесь, ощущение момента и жизни в нем — штуковина классная.

Что думаете? Вдруг кто уже пробовал свои методы? Будет интересно почитать)

😁😆😁 написать пост в канал …спросить у аудитории, как дела …испугаться, что никто не ответит …удалить вопрос Чистовик: ладно, сам расскажу: у меня ок, возвращаюсь с рабочей командировки, скоро буду дома. Всем отличных выходных⚡️

Коллеги, приветствую👋 Предлагаю за 5 минут проверить ваши навыки работы с Ansible. Если вы полагаете, что уверенно владеете инструментом, простое упражнение поможет объективно это оценить. Условия: 🔴Решите задачу — это займёт не более 5 минут. 🔴Каждый участник получит полезный подарок. 🔗 РЕШИТЬ ЗАДАЧУ

Опрос 📌 Мои коллеги из Слёрма сейчас активно работают над курсами по ИИ для айтишников. Думаю, многие из вас заметили, что ИИ из модной темы превращается в реальный инструмент, который меняет вашу работу каждый день Так вот, необходимо понять, куда двигаться дальше и как закрыть потребности рынка в знаниях 🙌 Если вы готовы погрузиться в ИИ глубже — скажите, какое направление вам наиболее интересно прямо сейчас. ⏩Проголосуйте в канале — это займёт 10 секунд, а Слёрму поможет сделать следующий шаг максимально полезным именно для вас!

Коллеги, приветствую 👋🏻 Как ваши дела? Я на этой неделе в командировке с командой, где мы и обсуждаем рабочие встречи и просто вспоминаем кто как выглядит) ⏩Захотелось вот что обсудить. Как вы подходите к важным работам на проде и какие случаи бывали? Я начал замечать, что часто самые важные работы проводятся в нерабочее время, которое является для системы менее нагруженным и безопасным с точки зрения недоступности. И вот даже если эти работы заранее планировать, то все равно что-то случается: то во время работ пропадает доступ, то изменения пересекаются с другими завершающимися работами. Сюда же сразу вспоминаются праздники и рождение детей 😁 Мне всегда нравились эти ответственные моменты, они объединяют усилия команд. ⏩Расскажу про случай, когда мы выполняли обновление системы, запланированное заранее на поздний вечер. Разделили работы на всех и сделали все по плану, кроме одного пункта. В нем было указано залить два раза один и тот же конфиг. Очевидно, что хватит и одного раза. Так подумали и мы, завершив все работы. И, конечно же, начались те самые сложно уловимые проблемы, которые не заметны сразу. В итоге, сэкономив на повторной заливке конфига – мы очень долго все отлавливали и восстанавливали, хотя в позднее время сил уже нет. В то время не было никакого DevOps-процесса, и конечно, конфиг грузился просто как огромный файл, человеческий фактор был очень важен. А повторная загрузка на самом деле позволяла обойти багу с тем, что загрузка конфига отваливаясь по таймауту, и подрезала конфиг... Поделитесь, у вас было нечто подобное?⬇️