Несколько лет назад, для закрытия одного их предметов мне довелось перевести данный букварь. Де-факто этот вариант стал официальным переводом. Но развитию этого перевода мешает, тот факт, что он был написан в Google Drive и закрыт на редактирования. Сегодня я уделил время на переформатирования всего этого текста в MD формат с помощью редактора Хабра, с радостью публикую здесь и вскоре отдам текущим контрибьюторам.

Словарь

Node — нода — узел с каким либо ресурсом
Content — контент — данныe
Traffic — трафик — запрос/ответ, данные которые передаются от сервера клиенту и наоборот
Hardware — железо — аппаратная часть
Instance — инстанс — созданный объект какой либо сущности. Например инстанс сервера API
Headers — хедеры — заголовки (как правило TCP пакета, но может быть и HTTP запроса)

---

Для приготовления auto-failover и auto-rejoin в docker swarm нам понадобится docker, postgres, repmgr, pgbouncer, runit и gluster. Можно также воспользоваться готовым образом.

Хорошая спецификация к API помогает клиентам его использовать. Несколько месяцев назад на большом Pytup разработчик Яндекса Александр Брязгин bryazginnn выступил с докладом о том, что собой представляет спецификация REST API на примере OpenAPI + Swagger и зачем нужна такая связка. Из конспекта можно узнать, как мы прикручивали автоматическую генерацию спецификации в уже готовом сервисе, какие библиотеки нам пригодились и какой есть тулинг вокруг спецификации OpenAPI.


— Всем привет, меня зовут Александр. Я хотел бы поговорить с вами про спецификации.

Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

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

Появление async/await в C# привело к пересмотру того, как писать простой и корректный параллельный код. Зачастую, используя асинхронное программирование, программисты не только не решают проблемы, которые были с потоками, но и привносят новые. Дедлоки и рейсы никуда не пропадают — их просто становится труднее диагностировать.



Дмитрий Иванов — Software Analysis TeamLead в Huawei, в прошлом техлид JetBrains Rider и разработчик ядра ReSharper: структур данных, кэшей, многопоточности, регулярный спикер конференции DotNext.

Под катом — видеозапись и текстовая расшифровка доклада Дмитрия с конференции DotNext 2019 Piter.

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

В .Net Core 3 добавилась отличная возможность передачи контекста корреляции в HTTP-заголовках, поэтому если ваши приложения используют прямые HTTP-вызовы для межсервисного взаимодействия, то вы можете воспользоваться этой коробочной функцональностью. Однако, если архитектура вашего бекенда подразумевает взаимодействие через брокера сообщений (RabbitMQ, Kafka и т.п.), то вам по-прежнему необходимо озаботиться темой передачи корелляционного контекста через эти сообщения самостоятельно.

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

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

• иметь единую точку входа с удобным анализом, чтобы инструментом логирования смогла пользоваться даже Поддержка, к которой летят вопросы вроде «у меня тут в приложении выскочила ошибка с таким-то айдишником запроса»

Привет, Хаброжители!

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

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

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

Это третья часть в серии статей "Учимся разворачивать микросервисы", и сегодня речь пойдет о Helm 3. В прошлой части мы создали Kubernetes конфигурацию для учебного проекта из 2 микросервисов (бекенда и шлюза) и задеплоили все это в Google Kubernetes Engine. В этой статье мы напишем Helm-чарт для нашей системы, создадим для него репозиторий на основе GitHub Pages и задеплоим проект в GKE с помощью Helm.

Доброго времени суток, %username%. Пора расчехлить блог после 6 лет простоя и попробовать опять что-то полезное принести сообществу.

Я крайне удивлен, что на хабре до сих пор нет ни одной статьи про Swarmpit. Я конечно понимаю, что наверняка большинство изучая Docker останавливаются собственно на нем и потом пытаются забраться на Эверест под названием Kubernetes. Не знаю точных чисел, но думаю тут большинство теряются и либо вообще забивают на Docker либо только его и используют. А зря!

Docker одна из горячих тем в разработке. Большинство новых проектов строится именно на Docker. Как минимум, он отлично зарекомендовал себя для распространения ПО, например, наша система поиска по документам Ambar устанавливается с помощью docker-compose.

В начале работы над Ambar мы использовали публичный docker-репозиторий, но с ростом проекта и появлением enterprise версии мы задумались над созданием собственного приватного репозитория. В данной статье мы поделимся своим опытом развертывания селф-хостед репозитория: пошагово опишем весь процесс, попытаемся обойти все подводные камни.

Exchange — обменник или точка обмена. В него отправляются сообщения. Exchange распределяет сообщение в одну или несколько очередей. Он маршрутизирует сообщения в очередь на основе созданных связей (bindings) между ним и очередью.

Exchange не является Erlang-процессом. Из соображений масштабируемости exchange — это строка (ссылка на модуль с кодом, где лежит логика маршрутизации) во встроенной базе данных mnesia. 1 тысяч обменников будут потреблять всего 1МБ памяти.

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

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

Изначально я разбил создание проекта на несколько шагов:

1. Создать два сервиса — 'бекенд' (backend) и 'шлюз' (gateway), упаковать их в docker-образы и настроить их совместную работу

   
   

   Ключевые слова: Java 11, Spring Boot, Docker, image optimization

   
   

2. Разработка Kubernetes конфигурации и деплой системы в Google Kubernetes Engine

   
   

   Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets

   
   

3. Создание чарта с помощью Helm 3 для более эффективного управления кластером

   
   

   Ключевые слова: Helm 3, chart deployment

   
   

4. Настройка Jenkins и пайплайна для автоматической доставки кода в кластер

   
   

   Ключевые слова: Jenkins configuration, plugins, separate configs repository

   
   

Каждому шагу я планирую посвятить отдельную статью.

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

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

Это вторая часть из серии статей "Учимся разворачивать микросервисы". В предыдущей части мы написали 2 простеньких микросервиса — бекенд и шлюз, и разобрались с тем, как их упаковать в docker-образы. В этой же статье мы будем организовывать оркестрацию наших docker-контейнеров с помощью Kubernetes. Мы последовательно составим конфигурацию для запуска системы в Minikube, а затем адаптируем ее для деплоя в Google Kubernetes Engine.

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

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

Для решения этой задачи мы решили использовать архитектуру обмена сообщениями через шину данных, и нам отлично подошел MassTransit с его Saga в связке с RabbitMQ.

Практики DevOps работают. Мы убедились в этом сами, когда сократили время установки релизов в 10 раз. В системе FIS Profile, которую мы используем в ВТБ, установка теперь занимает не 90 минут, а 10. Время сборки релиза снизилось с двух недель до двух дней. Число постоянных дефектов внедрения при этом упало почти до минимума. Чтобы уйти от «ручного труда» и устранить зависимость от вендора, нам пришлось пройти через работу с костылями и найти неожиданные решения. Под катом — подробная история о том, как мы построили полноценную внутреннюю разработку.

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

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

В сумме я работал руководителем лет 7-10 (точно не знаю, какие периоды сюда включать), но нулевая текучка сохранилась. Никто никогда от меня не уходил, никого никогда я не выгонял. Только набирал.

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

Всем привет, меня зовут Александр, я работаю в ЦИАН инженером и занимаюсь системным администрированием и автоматизацией инфраструктурных процессов. В комментариях к одной из прошлых статей нас попросили рассказать, откуда мы берем 4 ТБ логов в день и что с ними делаем. Да, логов у нас много, и для их обработки создан отдельный инфраструктурный кластер, который позволяет нам оперативно решать проблемы. В этой статье я расскажу о том, как мы за год адаптировали его под работу с постоянно растущим потоком данных.

На РИТ 2019 наш коллега Александр Коротков сделал доклад про автоматизацию разработки в ЦИАН: чтобы упростить жизнь и работу, мы используем собственную платформу Integro. Она отслеживает жизненный цикл задач, снимает с разработчиков рутинные операции и заметно сокращает количество багов в production. В этом посте мы дополним доклад Александра и расскажем, как прошли путь от простых скриптов к объединению open source продуктов через собственную платформу и чем у нас занимается отдельная команда автоматизации.
 

На Хабре с завидной периодичностью возникают посты от возмущенных программистов, которые справедливо (наверное) негодуют, почему на собеседовании никто не спросил про их прошлые проекты, не посмотрел их код, но задавал шаблонные справочные вопросы или заставлял решать алгоритмические задачи, которые, скорее всего (в 99%), не будут применяться на вакантной работе.

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

В этой статье я хотел бы рассказать о своем хобби-проекте поиска и классификации объявлений о сдаче квартир из социальной сети ВКонтакте и опыте его переезда на k8s.