Всем привет, меня зовут Артемий, я работаю старшим Android-разработчиком в команде пользовательского профиля в RuStore. Мой опыт в индустрии уже 8 лет. За это время я успел поработать в разных проектах и компаниях. У меня был опыт работы в проекте, в котором было свыше 300 модулей и больше 60 Android-разработчиков. Такие условия заставляют задуматься о масштабируемости на принципиально ином уровне.

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

В этой статье мы собираемся разобраться со следующими вопросами:

* Как виртуализировать сетевые ресурсы, чтобы контейнеры думали, что у них есть отдельные сетевые среды?

* Как превратить контейнеры в дружелюбных соседей и научить общаться друг с другом?

* Как выйти во внешний мир (например, в Интернет) изнутри контейнера?

* Как связаться с контейнерами, работающими на хосте Linux, из внешнего мира?

* Как реализовать публикацию портов, подобную Docker?

Привет, Хабр! Я работаю разработчиком в АльфаСтрахование – в команде, которая занимается электронным документооборотом

В чем суть проблемы, с которой мы столкнулись: несмотря на то, что документооборот внутри компании полностью электронный, на «входе» документы могут поступать к нам в самых разных форматах: отсканированные с бумажных носителей, в «цифре» с ЭЦП или без электронной подписи – чтобы обеспечить сквозную обработку таких документов, в ряде процессов нам требуется распознавать наличие подписи.

MongoDB — одна из самых популярных NoSQL/документоориентированных баз данных в мире веб-разработки, поэтому многие наши клиенты используют её в своих продуктах, в том числе и в production. Значительная их часть функционирует в Kubernetes, так что хотелось бы поделиться накопленным опытом: какие варианты для запуска Mongo в K8s существуют? В чем их особенности? Как мы сами подошли к этому вопросу?

Ведь не секрет: несмотря на то, что Kubernetes предоставляет большое количество преимуществ в масштабировании и администрировании приложений, если делать это без должного планирования и внимательности, можно получить больше неприятностей, чем пользы. То же самое касается и MongoDB в Kubernetes.

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

В статье «Почему всё ломается даже у хороших программистов?» (Часть 1 и Часть 2) был описан тип сотрудников: «золотая шестерёнка». Это способные люди, которые являются не только замечательными разработчиками, но ещё являются хорошими организаторами, имеют стратегическое мышление, могут проектировать архитектуру приложения либо даже ИТ-ландшафт. Встаёт закономерный вопрос, а почему «золотые шестерёнки» это плохо, почему бы из них не собрать сильную команду, чтобы всем было счастье. Давайте попробуем понять, почему «золотая шестерёнка» в итоге зачастую дестабилизирует ситуацию вокруг себя. Писать буду простым языком в расчёте на широкую аудиторию.

Многие компании используют сертификаты, подписанные внутренними удостоверяющими центрами (Certificate Authority) для ресурсов в приватных сетях. Поскольку такие сертификаты по умолчанию не могут быть доверенными, почти на каждом этапе вокруг пайплайна могут возникать ошибки такого рода: x509 certificate signed by unknown authority. Из-за этого до каждого компонента необходимо доставлять корневые сертификаты, используемые в компании. В статье расскажу, как это можно сделать.

Статья подготовлена на основе моего материала в курсе «CI/CD на примере Gitlab CI», первые его темы доступны в бесплатном мини-курсе.

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

Это инструкция по выбору решения и настройке прозрачного кеширования множества реестров контейнеров для CRI-O, Podman, Buildah, Skopeo и прочих инструментов, работающих с образами контейнеров OCI и использующих общую конфигурацию containers/common.