Введение в Kubernetes

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

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

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

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

Первая статья — концептуальное введение о необходимости оркестрации контейнеров без привязки к кубернетесу.

Вторая статья освещает основные концепции — cluster, nodes, pods, namespaces, кто на ком стоял.

Третья подробнее рассказывает о супер-важной штуке в кубере — подах (pods). Почему не хватает контейнера, из чего состоит под, в каких состояниях он может быть и как проверить его работоспособность.

Кто-то должен управлять всем развернутым зоопарком, предоставлять API для взаимодействия, решать на каком узле запустить под, контролировать работоспособность различных частей кластера и пытаться приводить всё к требуемому состоянию (desired state). Четвертая статья рассказывает о мастер-ноде и компонентах, которые берут на себя все эти задачи.

Пятая статья вводит ещё один набор концепций, которые активно применяются в кубернетесе — deployments, stateful set, daemon, jobs. Со всем этим неизбежно сталкиваешься на практике.

И заключительная, шестая статья рассказывает о том, как устроено взаимодействие различных частей в кластере, какие IP-адреса существуют, для чего они используются и как в обращении с ними помогают load balancer и ingress controller.

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

🔥, если интересна тема кубернетеса.
#skills

Доступаемся до ChatGPT

Нейросеть ChatGPT уже многие попробовали, и это просто вау! Для тех, кто ещё не пробовал — очень рекомендуем. Интересные варианты использования:
— можно решать и оптимизировать задачи на программирование. В комментариях к посту про быстрый поиск в 37 Гб файле подписчик уточняющими вопросами уровня "а как можно улучшить" заставил нейросеть пройти те же шаги, что и автор статьи

— проходить собеседования, причём и теорию, и практику. ChatGPT умеет писать код -__-

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

— писать рефераты и конспекты. Нам прислали интереснейший пример: для подготовки к экзамену студент ввёл "напиши небольшой конспект для экзамена на тему ХХХ" и получил действительно годную выжимку по вопросу. 20 минут и готов конспект для подготовки по всем вопросам к экзамену

Какие ещё есть примеры использования? Проявите фантазию и делитесь в комментариях.

Из грустного: сервис не работает из России, но думаем с VPN уже все разобрались :)

Также требуется регистрация. На этот случай рекомендуем удобный сервис BugMeNot. Просто вводите сайт, а в ответ будет предложены учетные данные для входа.

BugMeNot бывает полезен, когда не хочешь регистрироваться на каком-нибудь ресурсе.
#edu

Google Coding Interview With An Artificial Intelligence (ChatGPT)

В видео Clément Mihailescu, бывший Software Engineer из гугла, а нынче со-основатель площадки AlgoExpert, сервиса платной подготовки к интервью проводит mock google coding interview с чат-ботом. Иногда в процессе бот отваливался. Сами вопросы:
— напиши функцию определения палиндрома. Интересно то, что на повторный вопрос ChatGPT выдал совершенно другой код. Первый раз код был "в лоб", очень длинный и хорошо документированный. Второй раз код был в стиле Си-хакеров, пусть код и на JavaScript

— оцени сложность по памяти и времени этого алгоритма (space-time complexity). Автор комментирует ответы бота и восторгается, как внимательно в ответе раскрываются нюансы и граничные случаи

— поиск подстроки, которая является самым длинным палиндромом заданной строки. Вопрос с подвохом — решение в лоб имеет сложность O(n^3), а оптимальное решение O(n^2). Как вы понимаете, ChatGPT сразу выдаёт решение квадратичной сложности. Сам автор говорит, что когда-то не смог решить эту задачу на своём собеседовании в Lyft. Причём при очередной попытке задать этот же вопрос бот выдал решение O(n^3), но подметил, что это решение "не самое эффективное, но простое и его проще понять"

— хитрая задача про награду студентов. В этот момент я сдался, без подготовки такую задачу не решить. Обратите внимание, что бот документирует свой код, правильно решает крайние случаи, рассказывает, как пошагово работает код — все важные аспекты, которые должен учесть собеседуемый для получения оценки strong hire. Единственное, чего не делает бот — не задаёт уточняющих вопросов, но, вероятно, это связано с изначально детальной постановкой вопроса
#skills #резюме

JWT и его друзья

Хорошая заметка, чтобы вникнуть в token-based authentication.

Начинается всё банально — чем аутентификация отличается от авторизации. Дальше интереснее — access и refresh-токены. Что это, как устроены, почему они в паре и какое имеют отношение к авторизации.

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

Очень важно уметь правильно обращаться с токенами и хранить их. Во многих мануалах на просторах интернета учат, как делать проще, но не как делать правильно.

В заключение автор кратенько сравнивает JWT со столь привычными для многих cookie sessions и даёт несколько практических советов.

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

Для проекта средних размеров предлагаем взять популярное open source решение — Keycloak и развернуть его как сервис. Да, сначала будет непросто и нужно разобраться в особенностях. Но на длинной дистации это правильное решение.
#skills

Классные pre-commit хуки

Мы уже рассказывали, что на всех проектах используем утилиту pre-commit с линтерами. Но её можно настроить на другие полезные штуки. Нашли репозиторий с различными pre-commit хуками.

Нам показались интересными:
– проверка на добавление больших файлов в репозиторий. Бывает полезно, чтобы случайно что-то большое и лишнее не закомитить
– проверить, что исполняемые файлы содержат шебанг
– проверить корректность json-, toml-, xml-файлов
– проверить, что у файлов с тестами корректные названия. Это особенно важно, когда тесты автоматически прогоняются в CI/CD-пайплайнах
– проверить, что нигде случайно не комитятся секреты. Это частая проблема, когда в репозиториях находят какие-нибудь переменные окружения SECRET_KEY

Список не ограничивается перечисленным, загляните в репозиторий, может обнаружите что-то интересное для себя.
#skills

Manticore Search

Для полнотекстового поиска во многих проектах активно применяется Elasticsearch. Он же работает в системах для аналитики логов. Пример тому – всем известный ELK-стек. Но не эластиком единым.

Мы начали смотреть в сторону разных поисковых движков и пока остановились на Manticore Search.

Рекомендуем статью Manticore — альтернатива Эластику на C++. Автор начинает с исторической справки, как появился и развивался проект.

Дальнейшее повествование строится на сравнении с главным конкурентом – эластиком. Автор приводит множество интересных бенчмарков. Не будем говорить конкретные, загляните в статью и найдёте для себя что-то интересное. Особенно, если имеете опыт работы с эластиком.

Конечно, стоит критически относиться ко всем описанным тестам. Статья всё-таки подготовлена ребятами из мантикоры. Если бы статью писал кто-то из эластика, он бы нашел, о чём хорошем рассказать. Как говорится: если вы такие умные, то почему такие бедные?

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

Планируем попробовать мантикору в своём проекте. О причинах выбора и результатах расскажем позже.

В заключение, Manticore Search – заслуживающий внимания проект, о котором стоит знать, как о потенциальной альтернативе эластику.
#skills #database

Пятничное развлекательное

О важном когнитивном искажении. Во Вторую мировую возникла задача повышения защищённости военного самолёта при минимизации общего веса. То есть нельзя всё обшить бронёй, самолёт не взлетит. И есть статистика по американским бомбардировщикам, которые вернулись на базу — визуализация на скриншоте. Надо ли укреплять там, где больше всего пробоин?

Венгерский математик Абрахам Вальд решил, что укреплять нужно места без пробоин. Если самолёт с пробоиной вернулся на базу, значит, повреждение не критичное. Это называется систематическая ошибка выжившего — survivorship bias. Мы судим о вернувшихся самолётах и не учитываем сбитые.

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

Ставшие успешными Джобс, Гейтс и Цукерберг не закончили университет. Но не это причина их успеха. Вообще бесполезны рекомендации от успешных людей и важны истории поражений.

#fun

Backup: январь

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

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

Архитектура проекта
— Проектируем систему — System Design
— Практика распила монолита
— Жизненная история. Выбираемся из болота большого проекта
— БезТЗатый программист

Интересное по Python
— Python import: Advanced Techniques and Tips
— Классные pre-commit хуки
— Покоряем большие CSV

Используем базы данных
— Индексы в PostgreSQL
— Этапы выполнения запросов в PostgreSQL
— Manticore Search как замена Elasticsearch

Крутые базовые материалы
— Вспоминая git
— Признаки хорошего логирования
— Частичное клонирование репозитория

Строим веб-приложение
— Кажется, ваше приложение сейчас пятисотит
— Авторизация через OAuth и OIDC
— JWT и его друзья

Нейросети нас заменят
— Доступаемся до ChatGPT
— Google Coding Interview With An Artificial Intelligence (ChatGPT)

#backup

Практикуем Kubernetes

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

В этот раз посмотрим практическое руководство на официальном сайте кубера.

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

Все руководства, помимо практической части, сопровождаются теоретическими материалами.

Из приятного — можно ничего не устанавливать себе на компьютер, а пройти всё в терминале на сайте. Для большего погружения рекомендуем всё-таки развернуть у себя Minikube и делать практику локально.
#skills

Правильная структура ответа на собеседовании

Классический анекдот. Студент сдаёт экзамен по зоологии, а подготовился только к вопросу про блох. Тянет билет — там про собак. Начинает отвечать, что собака — млекопитающее, у неё есть голова, 4 лапы, хвост, всё это обильно покрыто шерстью, а в шерсти — блохи! И подробнейшим образом про блох. Преподаватель прерывает и просит рассказать про кошек. Студент снова: голова, усики, лапы, хвост и много шерсти, в которой — блохи, и опять про блох. Преподаватель снова прерывает и просит рассказать про рыб. Студент: тааак, рыбы., рыбы... плавают в воде, дышат жабрами, покрыты чешуёй. В чешуе блохи не водятся. Это спасает рыб от проблем с блохами. И снова про блох...

Рекомендуем версию этого анекдота с интересной историей из жизни про экзамен в РХТУ им. Менделеева. К чему это мы?

При ответе на собеседовании или на экзамене важно показать обширность и глубину ваших знаний. Выгодно максимально подробно отвечать, даже если ответ не совсем по теме. Забыли, что значит D в SOLID? Постарайтесь построить ответ так, чтобы максимально подробно рассказать про знакомые буквы. В процессе вспомнили другие темы, например, аббревиатуры, связанные с исходным вопросом? Пускайте в ход DRY, YAGNI, KISS, NIH-синдром, bus-factor и кучу другого материала, по возможности вплетая его в повествование. Высока вероятность, что собеседник забудет, что вы не до конца ответили на поставленный вопрос. Чем уместнее вы притянули смежные темы, тем менее заметна попытка скрыть незнание. Если тема совсем не к месту, то будет обратный эффект с обнаружением вашего незнания.

Кроме того, можете расставлять "ловушки". Намеренно допустите неточность в рассказе, на которую интервьюер среагирует наводящим вопросом, что ещё дальше отвлечёт его от исходного вопроса. Ляпните, что абстрактный класс и интерфейс — это одно и то же. На возмущённый уточняющий вопрос картинно задумайтесь, и дополните ответ, что не совсем одно и то же, и начните рассуждать о нюансах. Важно! Неточность можно допускать только там, где вы действительно хорошо ориентируетесь.

Но не злоупотребляйте таким приёмом. В работе важно уметь честно признать, что чего-то не знаешь. Нельзя знать всего, надо учиться у коллег, в том числе на правильном code review.

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

#devfm #sudo #edu #резюме

Многопоточный Python на примерах: избавляемся от дедлоков

Многопоточное программирование — это непросто. Самое неприятное — схватить дедлок, то есть взаимную блокировку потоков, когда поток 1 занял ресурс А и пытается захватить ресурс Б, а в это же время поток 2 занял ресурс Б и пытается захватить А. В этом случае потоки взаимно блокируют друг друга.

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

Примеры кода в статье взяты из небольшой опенсорсной библиотеки locklib. На заметку начинающим разработчикам — читать чужой код очень полезно. А тут приятное с полезным, автор разбирает чужой код за нас, дополняя его теорией.

По замерам автора, блокировка с проверкой на дедлоки в 10 раз медленнее, чем штатный питоновский threading.Lock. Такое замедление может оказаться неприятным, поэтому используйте с осторожностью.

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

#python

За всё хорошее, против всего плохого

В статье Software engineering practices представлен обширный набор советов. Разберём их подробнее.

Документация в репозитории
Недавно общался на эту тему с коллегой, и он продвигал необходимость вести документацию в Confluence. В конфлюенсе, действительно, можно писать более разухабисто, с перекрёстными ссылками на другие документы и всякой такой красотой. Но держать в актуальном состоянии подобную доку в конфле требует очень высокой дисциплины команды. Это может работать скорее против вас, чем за.
Я же согласен с автором статьи и считаю, что самый простой и надёжный способ держать документацию к сервису прямо в репозитории. Подробнее размышляли на эту тему тут.

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

Отработанный механизм миграций
Проблема миграций может оказаться бомбой замедленного действия. Памятуя кривой релиз, когда сидели всем селом и разгребали проблемы миграций. А потом ещё прилетело от какого-нибудь начальника за даунтайм. Разработчик будет идти на хитрости (читай — вставлять костыли), только бы не делать калечащих миграций.
Вообще тема миграций без даунтайма очень непростая. Про это у нас был отдельный пост.

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

Автоматическое форматирование кода
Про линтеры, которые активно и повсеместно используем писали тут. Отдельно отметим, что использование линтеров делает ваш код более приятным и снимает различные вопросы на код ревью.

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

#edu

Design distributed cache

Хочется порекомендовать замечательный youtube-канал System Design Interview. Автор вещает на понятном русском английском :)

Канал посвящён вопросам построения архитектуры. На нём мало видео, но каждое из них заслуживает внимания. При появлении типовой проблемы хорошо знать общие способы решения и не идти изобретать свой велосипед.

Например, видео о Distributed Cache. Автор не пытается сразу городить вундервафлю, выдавая готовое решение. Как и следует делать всегда при создании системы, сначала автор описывает проблему и рассуждает, чего мы хотим добиться, применяя кеш, какие есть функциональные и нефункциональные требования.

Всё достаточно просто, локальный кеш, LRU – алгоритм, применяемый для вытеснения данных при переполнении кеша. Дальше – интереснее, появляется распределённая система, и этот distributed вносит проблемы. Рассматриваются dedicated и co-allocated кластеры, способы управления кластером, какие алгоритмы применяются для распределения данных по шардам, их плюсы и минусы.

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

Вопрос, который не освещается в видео, но заслуживает внимания – прогревания кеша. Что делать при старте, когда кеши пустые?

P.S. У этого канала интересная история. Автор выпустил десяток добротных видео, получил много приятных отзывов и пропал на два года. Потом вернулся и сказал, что все это время готовил полноценный курс и не отвлекался. У нас пока руки не дошли посмотреть более подробно, но должно быть интересно.

#youtube #skills #резюме

Пятничное развлекательное

По пятницам у нас культурный код. Бэнкси – один из концептуальных художников современности, известный, по большей части, за граффити. В 2006 году Бэнкси выставил на аукцион картину Balloon Girl (Девочка с воздушным шаром), являющуюся копией его граффити 2002 года. В момент продажи картины дистанционно активировали шредер в раме картины. Трудно представить мысли нового владельца картины, на глазах которого 1 миллион фунтов стерлингов начал самоуничтожение. Результат прикрепим в комментариях, задумка выглядит интересной.

Позже картина была переименована в Love Is in the Bin (Любовь в мусорном баке). А в 2021 году её продали за 25 миллионов долларов.

Подробнее о Бэнкси на вики, более подробно тут.

В 2020 году вышел фильм Banksy с неплохим рейтингом. Вы смотрели? Как впечатления?

#fun #films

Как kafka хранит данные

Интересная статья A Practical Introduction to Kafka Storage Internals, посвящённая организации хранение данных в кафке.

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

Есть ещё одно понятие, о котором не так часто вспоминают при разработке, но оно важно при настройке кафки – сегменты. Сегменты – это более низкоуровневая абстракция. Именно из сегментов состоят партиции.

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

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

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

#skills

Буфферный кеш в PostgreSQL

Очередная серия статей от ребят из postgres. На этот раз о механизме журналирования, он же write-ahead log, он же WAL. Статьи не из лёгких и требуют серьезного погружения.

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

Когда кеш переполняется, что-то нужно вытеснить. Для этого используется алгоритм clock-sweep, который по кругу перебирает все буферы, уменьшает счётчики обращений, учитывает ещё разную хитрую магию и решает кого бы вытеснить.

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

Размер кеша – это, что рекомендуют менять сразу после развёртывания базы. По умолчанию он равен 128 Мб. Нет конкретного значения, которое стоит выбрать для кеша, всё зависит от задачи и лучше выяснять на практике. Автор рекомендует взять для начала 1/4 оперативной памяти. Также стоит учитывать, что postgres использует обычные вызовы операционной системы, поэтому происходит двойное кеширование – кеш СУБД и кеш ОС.

Горячий вопрос: прогрев кеша. В postgres для этого есть расширение pg_prewarm. С помощью него можно сразу прочитать в кеш данные определённых таблиц. Также можно сохранять состояние кеша и восстанавливать после перезагрузки сервера.

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

#skills #database

Моё разочарование в софте

Статья-нытьё про грустное состояние индустрии с точки зрения оптимизации. С момента выхода статьи прошло лет 5, лучше не стало.

Всё невыносимо медленно работает. Приложения огромные по размеру. Поддержка проектов прекращается всё быстрее, привет куче flash-игр. Управление зависимостями в программировании очень непростое.

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

Всё же не забывайте при разработке думать об оптимизации. Разница между загрузкой веб-страницы в 0.5 или 0.6 секунд может быть незаметна, но между 0.5 и 5 секундами целая пропасть. Не тащите в код зависимость, если она вам не нужна. Задумывайтесь о будущем. Но не занимайтесь оптимизацией ради оптимизации, решение бизнес-задачи всему голова.

Статья идейно перекликается с мыслями поста Страх и ненависть в ИТ.

#edu

Нестареющая классика, шпаргалка по SSH

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

Начинается с базы, коротко и по делу. Не нужно авторизовываться по паролю, настраивайте вход по ключу. Ключ генерируется одной командой и может быть закрыт паролем. Разумеется, ключ состоит из двух частей: открытой и закрытой. На сервер ключ можно скопировать ручками или специальной командой. У сервера есть свой ключ, который помещается в known_hosts. Для копирования данных через ssh-сессию есть команда scp. Это база. Теоретические основы были в отдельном посте.

Дальше, как всегда, интереснее:
– с помощью дополнительной утилиты sshfs можно предоставить доступ к удалённой файловой системе. При этом локальные приложения не будут подозревать, что работают с удалённой файловой системой

– можно выполнить команду на удалённом сервере, оставаясь в локальной командной строке. Интересное применение, например, вывести содержимое какого-то файла и с помощью конвейера скормить его локально запущенной программе

– если хотим вызвать удалённую команду, а её вывод поместить в локальный файл, то для этого можно пробросить stdin/out

– чтобы каждый раз не вспоминать ip-адрес, куда подключаешься, или, наоборот, не вспоминать длиннющее имя сервера, то для этого можно в конфиг файле ssh прописать алиасы

– если локальная машина имеет графический x-сервер, а удаленная нет, то можно сделать так, чтобы приложения с сервера рисовались у вас на рабочем столе

– публичные wi-fi совсем небезопасны, а VPN порой просто режут, поэтому есть выход – работа ssh в режиме socks-proxy

– заканчивается статья такими схемами, от которых волосы начинают шевелиться: проброс портов, вложенные туннели, реверс-сокс-прокси и проброс авторизации

Интересный факт, которым меня мучали в институте, и он упоминается в статье: ip-адреса 127.0.0.1 и 127.1 идентичны и нет никакой ошибки. Вот такие пироги.

#skills

Стратегии деплоя

Новую версию приложения можно выкатить по-разному. В статье Six Strategies for Application Deployment перечислено аж 6 стратегий деплоя. Какую выбрать – зависит от ситуации, золотой пули нет. Помимо описания самих стратегий автор приводит достоинства и недостатки каждой. Эти знания окажутся очень полезными, когда придется делать выбор в пользу какой-то одной. А ещё каждая из стратегий сопровождается наглядной анимацией. В общем, всё для людей.

Теперь о стратегиях.

Recreate – самый топорный вариант. Старая версия приложения гасится, новая запускается. Вот так стратегия :)

Rolling-update – постепенно выкатываются инстансы приложения с новой версией, по мере выкатки трафик переключается на них, старые инстансы постепенно гасятся.

Blue/Green – рядом с уже запущенным приложением запускается копия с новой версией, после некоторых health checks трафик полностью переключается на новую версию, а старая гасится.

Canary – почти как Blue/Green, только после выкатки новой версии сначала на неё пускается небольшое количество трафика. Убеждаются в стабильности работы и переключают весь трафик. После этого старая версия гасится.

A/B testing – как Canary, только обычно применяется для принятия некоторых бизнес-решений. Пользователей, которых направят на новую версию приложения, выбирают по некоторым условиям. Например, на новую версию направляются пользователи с определённой геолокацией или определённым браузером.

Shadow стратегия самая трудоёмкая для реализации. Рядом со старой версией выкатывается новая версия приложения и весь трафик дублируется на неё. То есть пользователь продолжает работать со старой версией, а мы можем посмотреть, как себя ведёт новая версия. Подвох заключается в том, что при использовании такой стратегии нужно не забыть замокать взаимодействие с третьими сервисами новой версии приложения. Иначе, например, с карточки пользователя может случайно списаться одна и та же сумма дважды :)

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

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

#skills

Полиморфизм на практике

10-минутное видео от ExtremeCode, то есть специфическое по юмору и лексике — будьте осторожны. Проектируем магазин товаров для взрослых, примеры кода на C#. Необходимо реализовать работу с разными товарами так, чтобы можно было легко добавлять новые товары. Хорошо показаны плюсы и минусы полиморфизма и его реальное применение.

Раньше мы уже предлагали крутое видео про ООП в целом.

#skills