Обычно я такими непотребствами не занимаюсь и уважаю частную жизнь приложений. Однако на днях мне довелось исследовать одно мобильное приложение написанное индусом в метро под iOS, а затем адаптированное под Android пьяным студентом «в комнате раздумий». Все действия выполнялись с целью дебага и понимания оптимальных условий для работы. Само приложение мы анализировать не будем, но подготовим среду для проведения исследований.

Эта статья не про взлом и даже не исследования безопасности. Этой статьёй я хочу разработчиков клиентских приложений немного углубиться в матчасть передачи данных поверх HTTPS и оценить риски в своих приложениях.

В предыдущей статье, я рассказал как можно упростить себе жизнь, воспользовавшись возможностями динамического инвентаря в виде скрипта. Это очень удобно, когда нужно вытянуть структуру хостов из какой-то системы со всеми нужными параметрами.

Но как я уже тогда сказал, этот способ зашит в ansible для быстрых решений. Более продвинутый, гибкий и переиспользуемый метод это написание собственного плагина. Но опять рассказывать про инвентарь мне стало очень скучно, поэтому в этот раз мы будем учиться подключаться и выполнять модули на целевом хосте.

Здесь я буду говорить о "потрохах" подключений ansible.

Если вы активно используете kubernetes в своей инфраструктуре, при этому у вас небольшая команда или она состоит в основном из разработчиков, то у меня к вам вопрос: ну как вам — стала жизнь легче? Наверное те, кто используют managed‑решения в некотором роде покивают головой, продавцы этих решений скажут «да!», с особенно довольным лицом, а бизнес, пуская скупую слезу, просто согласятся с большинством (ну бизнес же растёт).

Тот инструмент, про который я сегодня хочу рассказать подходит в большей степени для самого что ни на есть микросервисного и девопснутого подхода, когда команды разработчиков имеют необходимую и достаточную абстракцию для самостоятельного управления кластерами, при этом команда эксплуатации сохраняет контроль за всем. Речь пойдёт про Rancher и около стоящие продукты.

Может ли kubernetes сделать жизнь админов небольших и средних компаний проще или же это шайтан-машина для кровавого enterprise и оголтелых стартапов?

Итак, некоторое время назад я писал статью о том, как мы переехали на werf со скрипта. По большому счёту, это продолжение той истории. Задача встала такая: нужно максимально автоматизировано разворачивать свежее приложение на нескольких кластерах kubernetes, которое уже имеет обвязку для деплоя в виде werf. После некоторых изысканий, попыток использовать "коробочные" решения самой верфи и куба, я понял, что придётся написать собственный оператор, чтобы получить прям 100% покрытия всех "хотелок".

Чтобы у "гошников" прям конкретно подгорело, для этих целей я выбрал свой любимый Python и kopf.

В последнее время я всё чаще и чаще сталкиваюсь с тем, что Ansible используют таким образом, что этот комок костылей и граблей просто нереально разгребсти адекватному человеку без употребления фенибута или чего-либо мощнее. Одним из таких костылей является запуск анзибля в скрипте, чтобы предварительно сгенерировать inventory. Мне искренне непонятно, почему люди не читают документацию, а если и читают, то умудряются написать гигантский костыль в виде скрипта запуска, но не могут разобраться с тем, чтобы написать динамический инвенторий.

Это побудило меня написать такой маленький туториал по реализации динамического инвентория практически для любой версии Ansible. В качестве языка я выбрал Python, только потому, что его будет проще всего прочитать и адаптировать под любой другой язык.

Эта статья попытка поглумиться над безумием, которое творится в ИТ сейчас, и, в то же время, провести аудит имеющихся технологий в сфере DevOps культуры. Сама статья это выдуманная история, которая поможет понять, как рождаются модные веяния, почему они приходят и уходят, а главное покажет механизм трендов в развитии технологий. Несмотря на то, что история выдумана и является технической сатирой, все использованные фреймворки, технологии и облака вполне воспроизводимы и могут быть использованы по назначению (ссылки на документацию я оставляю намеренно).

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

Использование того или иного продукта в проекте - это всегда попытка найти лучшее решение, балансируя между ограниченным бюджетом, возможностями роста практически по любому сценарию и высотой "порога входа". Существует много продуктов, которые связаны с контейнерами, что выбрать подходящий инструмент становится всё сложнее и сложенее, а community с "промытыми мозгами" и мышлением "ёжиков жрущих кактус" только добавляет сложности (хотя в противовес оным есть хейтеры, которые наоборот обгадят решение, просто потому что в своё время оно им не подошло).

В целом, чтобы выбрать нужное решение чаще всего приходится поднять лабу, которая покроет 90% задач, чтобы понять насколько решение подходящее, а это значит пройти какую-то боль, потратить время и деньги. Но ещё помогают статьи, в которых рассматриваются частные случаи внедрения и подбор инструментов, чтобы научиться на чужих ошибках через объективный взгляд со стороны. Надеюсь, эта статья о том, почему и как мы пришли к решению с werf, поможет кому-то подобрать инструмент для своих нужд.

В 2015 году, когда я пришёл на своё текущее место работы, мне было непривычно от необыкновенной свободы действий. Буквально, на новом месте можно было проявить весь творческий потенциал как DevOps-евангелиста. Мне нравилось выстраивать процессы, автоматизировать рутину, делать разработку удобной. Больше всего я люблю оптимизации, а больше всего ненавижу - рутину.

Эта история одной боли и попытке не просто "принять обезболивающее", а реально излечить её. Поэтому готовьтесь переварить лонгрид.

У себя в компании я часто сталкиваюсь, что нужно поднять какой-то сервис, чтобы "общупать" его досконально. Хотя PCшники у нас довольно мощные, но большую часть ресурсов съедают PyCharm и Chrome, а на виртуалки с экспериментами очень часто остаётся совсем мало.

Поэтому мы завели у себя небольшую стойку с парой-тройкой серверов для экспериментов и локального Gitlab'а. Но что-то пошло не так и очень захотелось поиграться с чем-то новым.

На волне внедрения DevOps да и в целом развития ИТ в массах всё больше и больше становится популярным использование СПО (Свободное Программное Обеспечение). Даже Microsoft очень неплохо приложило руку к тому, чтобы популяризировать СПО в массах. Одна проблема — пользователи это потребители, а кто-то (наверняка кто-то да был) внушил этим пользователям, что в СПО действуют те же правила, что и в коммерческом софте, только при этом ничего не нужно платить.

Итак, давайте рассмотрим четыре логических ошибки, которые допускают пользователи в своём отношении к СПО. Всего четыре, потому что я считаю их наиболее важными.

Одним тёплым холодным зимним вечером, хотелось согреться в офисе и проверить теорию одного коллеги, что C++ vector мог бы быстрее справиться с задачей, чем CPython list.

В компании мы разрабатываем продукты на базе Django и случилось так, что нужно было обработать один большой массив словарей. Коллега предположил, что реализация на C++ была бы гораздо быстрее, а меня не покидало чувство, что Гвидо и сообщество наверное немного круче нас в Си и возможно уже решили и обошли все подводные камни, реализовав всё гораздо быстрее.

Для проверки теории, я решил написать небольшой тестовый файл, в котором решил прогнать в цикле вставку 1М словарей одинакового содержания в массив и в vector 100 раз подряд.

Результаты хоть и были ожидаемые, но так же и внезапные.

• распространить файл на 100 серверах
• распространить пакет на 100 серверах
• изменить строку в файле
• обновить систему
• добавить пользователя
• перезапустить сервисы

• Keystone
• Glance
• Nova
• Neutron
• Cinder
• Horizon