Проводя автотесты для скорости и надежности тестирования, в разработке и процессах CI/CD зачастую используют следующий стек технологий – Jenkins, Selenoid и Allure. Можно выделить несколько их преимуществ: у Jenkins это бесплатный доступ, большое количество возможностей и плагинов для расширения; у Selenoid – независимость окружений, каждый браузер запускается в отдельном контейнере; Allure, в свою очередь, в последние годы стал популярным инструментом для построения отчетов по результатам автотестов (подробнее об этом мы писали в прошлой статье). При этом информации о том, как эти инструменты можно сочетать, до сих пор достаточно мало, и мы хотим поделиться своим примером.

Итак, вы наконец-то стали счастливым обладателем k8s-кластера: получили его в наследство, в подарок на Новый год, заказали в DataLine) и т. п. У новых клиентов и даже у опытных пользователей часто возникает вопрос, как оценить кластер и проверить его работоспособность? 

В ответ мы написали этот мануал: при выполнении всех пунктов можно закрыть 95% вопросов о состоянии здоровья кластера. Поскольку проверка такой многокомпонентной системы может стать нетривиальной задачей, подойдем к процессу как можно проще.

Рады представить новую версию онлайн-самоучителя по werf, нашей CI/CD-утилите с открытым кодом!

Общая идея самоучителя — познакомить разработчиков с Kubernetes, показав на простых приложениях (готовы примеры для Ruby on Rails, Node.js и Laravel), как можно развертывать приложения в K8s с помощью werf. Это отличная возможность быстро освоить практические основы K8s без погружения в его объемную теоретическую базу. Если вы еще не решили, как провести новогодние каникулы с пользой, — вот вам идея.

Пошаговое руководство написания чат-бота на языке Python.

Установим Python и библиотеки на Debian, подключим PostgreSQL, получим вопросы и ответы, подключим морфологию и нормализуем слова, запустим чат-бота в Telegram.

Голая практика и полный листинг с комментариями.

Время от времени приходится слышать мнение от некоторых системных администраторов, а также некоторых 1С-разработчиков, что установка, настройка и поддержка PostgreSQL под Linux очень сложна. Что гораздо дешевле покупать лицензии Windows и Microsoft SQL Server, чем нанимать высококвалифицированных администраторов, которые будут администрировать все эти open-source системы.

На наших бизнес-приложениях, использующих в качестве СУБД PostgreSQL, работают 70% крупнейших розничных сетей в Беларуси. Во всех из них одновременно работают от 500 до 1500 пользователей. В приложениях реализованы практически все основные процессы розничных сетей (демо, чтобы оценить сложность). Размер баз данных на данный момент составляет от 2 до 4ТБ. И все они работают практически со стандартными настройками PostgreSQL на одиночных серверах без какой-либо кластеризации. При этом даже в самых загруженных серверах есть еще значительный резерв по ресурсам для дальнейшего увеличения нагрузки без потребности в кластеризации.

Да, конечно же, многое зависит от запросов к СУБД, и несколькими кривыми запросами можно положить весь сервер. Однако, точно также можно положить и Oracle, и MSSQL. Да, платформа lsFusion, на которой написаны наши приложения, делает много различных оптимизаций запросов конкретно под PostgreSQL. Но вручную SQL-запросы можно оптимизировать еще лучше.

В этой статье я полностью опишу все настройки PostgreSQL (и немножко ОС), которые мы делаем на наших системах. Кроме того, мы специально стараемся не изменять те настройки, которые не дают видимого изменения в производительности, чтобы потом не гадать, почему в одном окружении есть проблема, а в другом - нет.

Bash, он же возрождённый shell, является по-прежнему одним из самых популярных командных процессоров и интерпретаторов сценариев. Как бы его ненавидели и не пытались заменить, всё равно он присутствует вокруг нас и никуда не собирается исчезать. Если вам приходится писать bash скрипты или вы только планируете этим заняться, данная статья написана для вас.

Всех приветствую! Недавно перед нашей командой DBA предстала задача по перемещению ансамбля ZooKeeper на другие сервера. Проблема оказалась в том, что в просторах интернета нет доступного руководства для ZooKeeper версии 3.6.2 и выше. Нашлось руководство для версии 3.4.5, но таким образом расширить и переместить наш ансамбль мы не решились.

Может появиться вопрос: Почему нельзя просто переместить файлы на другой сервер и запустить ансамбль там? Наш ансамбль хранит данные по слиянию и реплицированию данных кластера Clickhouse.

Шел 2021 год, русские хакеры продолжают переигрывать и уничтожать загнивающий Запад, вмешиваясь в выборы, ломая фейсбуки и пентагоны. Тем временем на Хабре выходят статьи о создании неубиваемых Kubernetes-кластеров, которые, по видимому, всех нас переживут. А кто-нибудь подумал о простых пацанах (пацанессах)??? Как быть обычному программисту, который хочет свой небольшой кластер и ламповый CI/CD с автодеплоем приложения, чтобы кенты с района не засмеяли?

Всем привет, меня зовут Алексей и я алкоголик разработчик на Python/Go в Домклик. Сегодня мы будем понижать порог входа в self-hosted Kubernetes и GitLab AutoDevops.

Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.

С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).

Круто, что docker реально ускоряет разработку во множество раз. Если вести ее правильно, то даже без потери в качестве. В любом случае, docker здесь, от него не деться и приходится им пользоваться.

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

Disclaimer: все написанное ниже является личным мнением автора и может как отражать реальность, так и не отражать реальность. Материал строго провокационного характера и основной целью является не унизить или обидеть кого бы то ни было, а скорее заставить людей включить голову и осознать масштабы глубин (с).

Давайте рассмотрим вопрос о авто обнаружениях в Zabbix не предусмотренных разработчиками, но очень нужные для решения ряда задач.

Пару месяцев назад, когда Oracle представила в своем публичном облаке двухсокетные серверы с 80-ядерными ARM-процессорами, в англоязычном блоге Тодда Шарпа появилась статья о том, как запустить сервер Minecraft в облаке. Теперь, когда Oracle добавил эти процессоры в Always Free Tier, все стало еще интереснее — вы можете совершенно бесплатно и неограниченно создавать и использовать виртуальные машины, использующие в общей сложности 4 ядра и 24GB памяти. Однако за два месяца изменился интерфейс Публичного Облака Oracle и версии программ, которые применяются для запуска сервера Minecraft. Поэтому сегодня я хочу поделиться своим опытом прохождения этого же пути — с учетом изменений и подводных камней, а также в русскоязычным интерфейсом. Всех любителей Minecraft, а также заинтересованных в создании бесплатных виртуальных серверов, прошу под кат!

Цель этой статьи показать и объяснить многообразие дистрибутивов Линукс. Показать основные сходства (они же все почему то называются "Линуксы" или даже правильнее "GNU/Linux") и основные различия (если бы не было различий их бы столько не существовало).

Плюс рассмотрим несколько наиболее задаваемых новичками вопросов:
- Сколько их (Linux-дистрибутивов)? Зачем так много?
- Основанный на другом дистрибутиве" - не пиратство ли это?
- Платный Linux - Как можно продавать то, что по определению распространяется бесплатно?
- Что такое "отечественный Linux"?

Исторически мы использовали GitLab 8, который работал на хосте Mac на VirtualBox. Потом конфигурация перестала устраивать, поэтому в локальной сети завели отдельную полноценную Ubuntu-машину. Заодно и GitLab обновили до версии 11.2.1-ee.

Ставили все по официальному гайду. При установке postfix возникли ошибки из-за цифры в имени хоста (решилось переименованием), в остальном сложностей не было. Зато они появились позже: гит-машине перестало хватать памяти на объекты, мы подключили LFS и решили проблему, но потом сломались бэкапы. В общем, было весело. О том, как все это чинили — рассказал под катом.

... а также 13 навыков, которыми надо овладеть, если хотите перейти из сисадминов в менеджеры – мы собрали для вас коротким дайджестом список полезных материалов, найденных нами в сети за последние две недели в нашей постоянной рубрике #полезногопост

Казалось бы простая задача - развернуть Kubernetes кластер и в нем запустить централизованный мониторинг TICK стек и логирование ELK стек. Но для меня она осложнилась тем, что с этим технологиями я столкнулся впервые. Чтобы понять, как все работает, хотел пройти простые Quick Start инструкции. К своему удивлению, не нашел детальных актуальных описаний - либо отдельные статьи со своей спецификой, либо многостраничные книги по Kubernetes. Пока собирал пазл из многочисленных материалов, решил написать статью, в которой рассмотреть общую концепцию развертывания TICK и ELK стеков в Kubernetes. 

Для чего, вообще, решать задачу централизованного мониторинга и логирования в Kubernetes? 

Сегодня состоялся долгожданный публичный Open Source-релиз нашей платформы для автоматизации обслуживания кластеров Kubernetes — Deckhouse. Этому предшествовало три с половиной года внутренней разработки и эксплуатации платформы на многочисленных и весьма разнообразных проектах. Сейчас с помощью Deckhouse мы обслуживаем в production более 170 кластеров (3500+ узлов), в которых развернуто около 3000 приложений. Deckhouse — это квинтэссенция нашего опыта в эксплуатации Kubernetes-кластеров и кульминация всей связанной с этим производственной деятельности последних лет.

Мы начали выдавать ранний доступ к платформе и демонстрировать её возможности ещё в мае, на конференции HighLoad++. Уже более 300 человек смогли самостоятельно попробовать Deckhouse. Пришло время поделиться нашим опытом автоматизации Kubernetes с более широким сообществом!

Хабру катастрофически не хватает такого формата постов как "продолжение" или "дополнение". После написания статьи зачастую появляется материал, который хотелось бы добавить к сказанному, но update'ить статью, с её сроком жизни в 1-2 дня, бессмысленно, а писать в комментариях невозможно из-за объёма материала. В то же время этого материала может быть недостаточно для новой статьи, да и, в силу того, что он сильно перекликается с предыдущей статьёй, придется либо постоянно её цитировать, либо оставлять пробелы, подразумевая, что читатель понимает о чем идет речь.

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

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

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

Я много внимания уделила тому, насколько та или иная техника может вас выдать. И надеюсь, что аналитики SOC вынесут из статьи хотя бы несколько вещей, на которые стоит обращать внимание.

Буду благодарна за любую обратную связь. Если вдруг вы знаете еще какие-то техники или интересные приемы, о которых я не написала, обязательно поделитесь. Потому что процесс закрепления в системе очень творческий. Особенно, если у вас есть права root.

Приветствую всех любителей Infrastructure as Code.

Как я уже писал в предыдущей статье, я люблю заниматься автоматизацией инфраструктуры. Сегодня представляю вашему вниманию вариант построения GitOps для реализации подхода Monitoring as Code.