![](https://webcf.waybackmachine.org/web/20230604065522im_/https://habrastorage.org/r/w1560/getpro/habr/upload_files/800/63c/9e8/80063c9e894a0ad1bf1b73d230d9a370.png)
Приведу несколько распространённых стратегий развертывания приложений/сервисов, а также разберу пять популярных стратегий «жонглирования» данными между системами кеширования и базами данных.
Методология разработки программного обеспечения
Приведу несколько распространённых стратегий развертывания приложений/сервисов, а также разберу пять популярных стратегий «жонглирования» данными между системами кеширования и базами данных.
Развёртывание ПО, или деплой (deploy) — этап в разработке, в Devops в целом, это действия, которые делают ПО готовым к использованию. Если вы умеете в грамотный деплой, масштабирование и управление конвейерами (CI/CD), то ваш софт будет конкурентоспособным.
Далеко не все компании могут позволить себе нанять целую команду DevOps инженеров, чтобы управлять развёртыванием. Но здесь важно не количество разрабов, а качество их знаний. Есть инструменты, с которыми можно эффективно деплоить и без большой команды.
Мы в digital-агентстве успешно используем GitLab CI и Docker для развёртывания ПО в разных средах. Для чего нужны эти инструменты?
GitLab CI позволяет автоматизировать процессы сборки и доставки ПО. Docker — упаковать приложение и его зависимости в контейнеры, что упрощает развёртывание и масштабирование в разных средах. Используя их, вы сократите затраты на найм и оптимизируете деплой.
В этой статье расскажу о нашем опыте и покажу примеры настройки конвейеров CI/CD, как ими управлять с помощью GitLab CI и Docker. А также дам рекомендации, как масштабировать развертывание.
Требовалось кешировать используемые в разных проектах NPM пакеты (+ хранить свои пакеты) на отдельном сервере.
Было решено делать это с помощью репозитария Verdaccio (по нему есть достаточно хорошая офф. дока), крутится это все должно в Docker, а разворачиваться на отдельном сервере через GitLab CI/CD.
Т.к. реализация данной схемы заняла у меня некоторое время (Хотелось бы и по меньше), решил написать короткий туториал по этой теме, с описание нюансов, которые для меня казались не очевидными.
Привет! Меня зовут Петр Бобров, в QIWI я отвечаю за отказоустойчивость, расскажу немного историй про сторонних вендоров, у всех они разные. У нас есть карточный процессинг, потому что мы банк, у нас банковская лицензия, проводим много платежей. Еще можно черными ящиками считать и базы данных: кто знает, как там работает Oracle, кто знает, как работает Linux внутри? Думаю, очень немного людей разбирается в этом, как оно работает на низком уровне.
Мониторить такие вещи достаточно проблематично, особенно, если нужно соответствовать стандарту PCI/DSS, который запрещает выкладывать логи приложений в общий доступ, потому что там потенциально хранятся определенные карточные данные в открытом виде, а в софте отсутствуют какие-то вменяемые интерфейсы, которые тебе могут посылать данные в твои системы мониторинга. В общем, проблем достаточно много, даже бывает такое, что говорили: «Не лезьте со своими SQL-запросами в нашу базу, вы портите нам производительность». Ситуация удручающая, так что мы захотели как-то это поправить.
Сейчас я покажу пример самописного мониторинга, который я сам мог сделать своим ограниченным интеллектуальным ресурсом. В этом примере мне хочется сфокусироваться на (не)сложности его реализации, а не на содержательном компоненте постановки задачи, хотя мне он тоже был довольно интересен.
Привет, Хабр! Меня зовут Алексей Колосков, я DevOps/Cloud-инженер в Hilbert Team. Вместе с моим коллегой Михаилом Кажемским в этой статье мы расскажем об особенностях DevSecOps-пайплайна и концепции Shift Left. Вы узнаете об основных этапах DevSecOps-пайплайна, автоматизированных проверках безопасности при разработке ПО, бесплатных и опенсорс-инструментах. Также найдёте советы, которые помогут раньше обнаруживать уязвимости и улучшать безопасность приложения.
Статья поможет оценить зрелость вашего DevSecOps-пайплайна, разработать дорожную карту его развития, выбрать правильные инструменты для каждой задачи и лучше понять, как управлять проектами в соответствии с философией DevSecOps.
Привет!
Меня зовут Антон Башарин, я работаю в компании Swordfish Security и занимаюсь построением и автоматизацией процессов разработки защищенного ПО, в том числе интеграцией практик информационной безопасности в DevOps. Вместе с моей коллегой Анастасией Арсеньевой мы собрали в один материал основные проблемы, чаще всего встречающиеся при обработке уязвимостей ИБ, и постарались разобраться, как можно оптимизировать этот процесс с помощью инструмента класса ASOC. Ниже описаны решения и «показана» эффективность их применения с помощью дашбордов, которые мы разработали для модуля визуализации метрик DevSecOps в рамках развития нашего продукта AppSec.Hub, реализующего практику ASOC. Мы взяли эту платформу лишь с той целью, чтобы с практической точки зрения раскрыть спектр возможностей решения класса ASOC. Итак, поехали!
Не секрет, что микросервисы мало запустить. За их работой нужно следить, чтобы не было сбоев, а следовательно и недовольных пользователей. Для этого, нужны системы мониторинга и логирования. Команда платформы dBrain собрала свой универсальный стек системы мониторинга. Сегодня расскажем, какие проблемы возникают с мониторингом и как их решить.
Как работает связь между подами в Kubernetes?
Как трафик достигает пода?
В этой статье вы узнаете, как работает низкоуровневая сеть в Kubernetes.
Хорошего времени суток, господа и дамы. Меня зовут Илья, и если вы занимаетесь автоматизацией тестирования на проекте, и ваш проект использует Vercel, то этот мини-гайд для вас.
Подробно и на примере рассматриваем проблему deployment bottleneck и как она появляется. Рассказываю как можно легко и быстро настроить реплицируемые stage-окружения для ее решения, дав разработчикам делать свою магию параллельно и независимо друг от друга.
Есть такие ребята — SRE (с англ. Site Reliability Engineering), которые выросли из старых добрых и бородатых системных администраторов. Но они устали заниматься ежедневной рутиной и решили всё автоматизировать. Именно поэтому 50% времени SRE пишут код.
В современном быстро меняющемся цифровом мире автоматизация является важной частью стратегии любой организации. С распространением облачных вычислений, DevOps, непрерывной интеграции и доставки спрос на инструменты автоматизации вырос в геометрической прогрессии. Ansible — инструмент автоматизации с открытым исходным кодом, который стал одним из самых популярных решений для автоматизации управления инфраструктурой, развертывания приложений и управления конфигурацией.
В этом посте мы рассмотрим, как Ansible может помочь вам автоматизировать всё в вашей инфраструктуре.
Ansible обеспечивает простую IT-автоматизацию, берет на себя повторяющиеся задачи и позволяет DevOps-командам заниматься более стратегической работой. В этом посте мы узнаем, как развернуть веб-сайт на нескольких экземплярах AWS EC2 с помощью плейбуков Ansible без установки сервиса на каждый сервер отдельно.
В любой организации имеются ролевые почтовые адреса (типа [email protected] или [email protected]) с которыми коллективно работает группа сотрудников . В некоторых почтовых системах (как например MS Exhange), поддержка таких адресов уже зашита в логику программного обеспечения. В других случаях приходится самим подбирать различные технические подходы. Давайте рассмотрим их подробнее.
В этой статье мы рассмотрим память внутри контейнера Kubernetes. Какие есть основные типы памяти, как они управляются и какие коварные моменты с ними связаны. В этой статье вы узнаете ответы на интересные вопросы:
• Какие метрики памяти считаются неправильно?
• Сколько раз надо прочитать файл, чтобы он хорошо закешировался?
• Какую память учитывает Out-of-memory killer?
В марте сервисы Datadog не работали более суток. Что пошло не так, как отреагировала команда инженеров, и что можно извлечь из этого инцидента? Это перевод эксклюзивного исследования, которое провел Гергели Орош (Gergely Orosz), консультант mobile.dev, автор нескольких книг по работе с инфраструктурой, в прошлом — инженер в Uber, Skype, Microsoft.
Из-за того, что наша компания занимается аутсорсом разработки, в работе одновременно много проектов. На разработку и поддержку каждого требуется много времени и ресурсов.
Мы уделяем большое внимание инфраструктуре и различным способам повышения эффективности разработки. В общем, по сути это и есть DevOps — Development & Operations. Только отдельных специалистов для этого у нас не было, и задачи закрывали хаотично и силами лидов.
В какой-то момент основатели KTS поняли, что услуга может быть актуальна на рынке: если у нас есть такая проблема, значит и другие компании с ней сталкиваются.
В статье рассказываю, как запустить новую услугу в компании по уму, а не как это обычно бывает.
Допустим, вам нужно перенести хранилище данных из одного кластера в другой. А выключать его нельзя, потому что это может вызвать незначительный (или значительный) коллапс сервисов, которые с ним работают. В статье мы расскажем о не самом очевидном и популярном способе переноса etcd из одного облачного кластера Kubernetes в другой. Такой способ поможет избежать простоя и связанных с ним последствий. Согласно стартовым условиям, оба кластера находятся в облаке, а потому нам предстоит столкнуться с некоторыми ограничениями и трудностями — им мы уделим особое внимание.
Примечание: Сразу оговорим, что речь идет про миграцию не того etcd, в котором Kubernetes хранит все состояние кластера. В статье описана миграция отдельной инсталляции etcd, которая используется сторонними приложениями и находится внутри кластера k8s.
Ваш аккаунт