Привет, Хабр!

Ansible — это инструмент для автоматизации, который облегчает управление конфигурациями, развертывание приложений и оркестрацию сложных задач. Его главная сила заключается в простоте использования и высокой читаемости плейбуков, которые представляют собой сценарии автоматизации, написанные на YAML.

Плейбуки в Ansible — основной инструмент Ansible. Плейбук состоит из одного или нескольких игр (plays), каждая из которых, в свою очередь, содержит задачи (tasks). Эти задачи выполняются последовательно, что позволяет создавать сложные, но легко читаемые сценарии автоматизации.

В этой статье мы рассмотрим как работать с плейбуками в Ansible.

В современном мире телеграм-боты стали неотъемлемой частью нашей повседневной жизни. Они стали незаменимыми в самых разнообразных задачах – от автоматизации повседневных операций до обеспечения клиентов высококачественным сервисом.

Иногда бывает так, что возникает необходимость создать собственного телеграм-бота. Меня тоже коснулся этот момент. Начав искать готовые решения, столкнулся с небольшим разочарованием: оказалось, что подходящих фреймворков нет, и придется разрабатывать бота с нуля.

Не страшно! В этой статье я поделюсь с вами всеми этапами создания собственного фреймворка для телеграм-бота с использованием C#.

Давайте проведем небольшой эксперимент. Вспомните лучшую книгу по вашей специальности или области разработок. Сколько по времени вы можете воспроизводить ее содержание?

Чаще всего это не более минуты.

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

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

Глобальный каталог LDAP стал неотъемлемой частью современной ИТ инфраструктуры любой крупной организации. Сама технология каталога LDAP у большинства плотно ассоциируется с Active Directory от Майкрософт. Однако сейчас все больше организаций пытаются уйти от решений данного вендора и перейти на софт с открытым исходным кодом.

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

Туториалы делятся на две больших категории: либо "как нарисовать сову", либо подробно расписанные тысячи шагов в формате "напиши туториал для дурака - и только дурак захочет его читать".

Как какой из двух категорий относится эта статья — решать вам.

В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.

Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.

Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).

Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.

Добрый день, меня зовут Евгений Кузаков.

В силу рода деятельности (я руководитель DevOps-практики) периодически встают задачи сайзинга оборудования для новых кластеров Заказчиков.

Обычно разработка начинается на кластерах разработки в недрах компании.

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

В противном случае будут наблюдаться как минимум следующие проблемы:

Helm Charts мощный и гибкий инструмент управления ресурсами в Kuberenetes.

А что если одним чартом пользуются несколько команд для деплоя своих приложений в Kubernetes? Как гарантировать, что чарт как минимум может отрендериться, прежде чем публиковать чарт в репозиторий артефактов? Как гарантировать, что новая версия чарта не "сломает" деплой приложений в критический момент(на продакшн)?

Этими вопросами задался и я при разработке такого чарта.

Работаю в IT больше 15 лет. Чем только не занимался, но всегда следовал правилу - каждые майские праздники я пытаюсь применить на практике что-то новое.

В этом году я прочитал книгу Event Driven Microservices и загорелся потрогать Kafka как настоящий брокер событий, а не сообщений.

Идей было много, но мне хочется проверить все это под реальной нагрузкой, что сразу привело в телеграм боты, где получить +- 1000 пользователей труда не составляет.

Я все детство провозился с ASCII играми в DOS и идея пришла сама собой.

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

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

RBAC (Role-based access control) — это система распределения прав доступа к различным объектам в кластере Kubernetes.

Объекты в кластере Kubernetes — это YAML-манифесты, а права доступа определяют, какому пользователю можно только просматривать манифесты, а кто может их создавать, изменять или даже удалять.

Рассказываем, как устроен RBAC.

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

Привет, Хабр! Относительно недавно после пары лет перерыва в айти, потраченных на изучение японского языка, мне пришлось срочно обновлять свои знания на работе. Ну знаете, искать возможности исполнить все хотелки начальника, как и положено эникею. Меня ждало много увлекательных открытий, но при этом, как водится, и немало боли и борьбы с непонятками. Docker, контейнеры, реверс DNS и реверс прокси, получение TLS сертификатов. В какой-то момент я наконец дошёл до удобного решения, которым я теперь хочу поделиться.

В своё время домашний сервер очень облегчил бы мне понимание Docker’а, да и удобство работы с ним неслабо бы повысил. Поэтому возникла идея написать эту статью, после прочтения которой любой человек даже с поверхностными знаниями в информационных технологиях сможет поставить себе постоянно доступный домашний сервер на базе Docker Swarm с удобной веб-мордой, простым получением TLS-сертификатов и Heroku-подобным функционалом (для чего будем использовать PaaS CapRover). 

Статья, в общем-то, рассчитана на новичков, обладающих какими-то техническими знаниями — школьников старших классов, студентов и просто любителей — а потому вряд ли будет интересна серьёзным профессионалам.

В данном курсе планируется разобрать основные особенности программирования на самой простой реализации assembler – TASM. Этих знаний лично мне вполне хватило, чтобы на отлично сдать ЭВМ в институте и закончить все лабораторные работы. Во многих уроках будет домашние задание по их мотивам.

Для начала давайте установим наш старенький компилятор.
Ссылка

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

Функциональность, которая не доступна в Kubernetes «из коробки», здесь почти не будет затрагиваться. Также мы не будем привязываться к конкретным CD-решениям и опустим вопросы шаблонизации/генерации Kubernetes-манифестов. Рассмотрены только общие правила, касающиеся того, как Kubernetes-манифесты могут выглядеть в конечном итоге при деплое в кластер.