🗄️Подборка каналов для каждого безопасника и сетевика
🛡ZeroDay - уроки по кибербезопасности и хакингу от нуля до профи, вирусы, взломы, osint, криптография и свежие новости
🌐 Серверная Админа - большое количество уроков и статей по устройству компьютерных сетей. Кладезь информации для безопасника
🛡ZeroDay - уроки по кибербезопасности и хакингу от нуля до профи, вирусы, взломы, osint, криптография и свежие новости
🌐 Серверная Админа - большое количество уроков и статей по устройству компьютерных сетей. Кладезь информации для безопасника
Вышел релиз GitLab 16.7 с GitLab Duo Code Suggestions в общем доступе и бета-версией каталога CI/CD
https://about.gitlab.com/releases/2023/12/21/gitlab-16-7-released/
#devops #девопс
Подпишись 👉@i_DevOps
https://about.gitlab.com/releases/2023/12/21/gitlab-16-7-released/
#devops #девопс
Подпишись 👉@i_DevOps
GitLab
GitLab 16.7 released with general availability of GitLab Duo Code Suggestions and CI/CD Catalog in Beta
GitLab 16.7 released with general availability of GitLab Duo Code Suggestions, CI/CD Catalog in Beta, new drill-down view from Insights report charts, SAST results in MR changes view, and much more!
👍3
Sre-checklist
Контрольный список для всех, кто занимается проектированием надежности сайта
🎯 Цель: Дать командам и отдельным людям представление о том, что нужно учитывать и к чему стремиться в области SRE и в работе.
Примечание: эти контрольные списки составлены с учетом моего мнения. Они основаны на моем собственном мнении и опыте и не являются универсальной истиной (да! 😄). Поэтому вы должны сомневаться во всем, что здесь прочитаете, и вы можете высказать свое собственное мнение по этому вопросу, начав обсуждение или предложив изменения в проект
🚧 Вы можете сказать, что этот репозиторий все еще находится в процессе разработки. Я бы не стал рассматривать его как полный исходный код на данный момент или что-то близкое к этому. Вклад в проект более чем приветствуется!
https://github.com/bregman-arie/sre-checklist
#devops #девопс
Подпишись 👉@i_DevOps
Контрольный список для всех, кто занимается проектированием надежности сайта
🎯 Цель: Дать командам и отдельным людям представление о том, что нужно учитывать и к чему стремиться в области SRE и в работе.
Примечание: эти контрольные списки составлены с учетом моего мнения. Они основаны на моем собственном мнении и опыте и не являются универсальной истиной (да! 😄). Поэтому вы должны сомневаться во всем, что здесь прочитаете, и вы можете высказать свое собственное мнение по этому вопросу, начав обсуждение или предложив изменения в проект
🚧 Вы можете сказать, что этот репозиторий все еще находится в процессе разработки. Я бы не стал рассматривать его как полный исходный код на данный момент или что-то близкое к этому. Вклад в проект более чем приветствуется!
https://github.com/bregman-arie/sre-checklist
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Руководство по GitOps: ArgoCD против Flux
GitOps стал чрезвычайно популярным способом управления инфраструктурой и приложениями Kubernetes. Используя Git в качестве единого источника, GitOps позволяет использовать инфраструктуру как код и автоматизировать развертывание приложений в Kubernetes. Этот подход сегодня используют многие компании, поэтому я хотел поделиться нашим путешествием по GitOps в серии постов на эту тему.
https://www.codereliant.io/gitops-guide-argocd-vs-flux/
#devops #девопс
Подпишись 👉@i_DevOps
GitOps стал чрезвычайно популярным способом управления инфраструктурой и приложениями Kubernetes. Используя Git в качестве единого источника, GitOps позволяет использовать инфраструктуру как код и автоматизировать развертывание приложений в Kubernetes. Этот подход сегодня используют многие компании, поэтому я хотел поделиться нашим путешествием по GitOps в серии постов на эту тему.
https://www.codereliant.io/gitops-guide-argocd-vs-flux/
#devops #девопс
Подпишись 👉@i_DevOps
👍7
Пробки в облаке: Перегрузки снижают надежность ваших приложений?
Представьте себе оживленную систему автомагистралей - сложную сеть дорог, мостов, туннелей и перекрестков, каждая из которых рассчитана на определенный объем движения. А теперь подумайте о событиях, которые приводят к пробкам: авариях, дорожных работах или внезапном наплыве автомобилей. Эти происшествия вызывают заторы на дорогах, и часто затор на одном участке шоссе вызывает затор на другом. Например, затор на мосту может привести к затору на дороге, ведущей к нему. Заторы создают множество проблем, начиная от задержек и увеличения времени в пути и заканчивая раздражением водителей из-за потерянного времени и слишком большого количества сожженного топлива. Такие сбои в работе наносят ущерб не только водителям, но и всей экономике. Задерживаются товары, нарушается предоставление услуг, поскольку сотрудники приходят на работу с опозданием (и в раздражении).
https://blog.fluxninja.com/blog/traffic-jams-in-the-cloud-unveiling-the-true-enemy-of-reliability
#devops #девопс
Подпишись 👉@i_DevOps
Представьте себе оживленную систему автомагистралей - сложную сеть дорог, мостов, туннелей и перекрестков, каждая из которых рассчитана на определенный объем движения. А теперь подумайте о событиях, которые приводят к пробкам: авариях, дорожных работах или внезапном наплыве автомобилей. Эти происшествия вызывают заторы на дорогах, и часто затор на одном участке шоссе вызывает затор на другом. Например, затор на мосту может привести к затору на дороге, ведущей к нему. Заторы создают множество проблем, начиная от задержек и увеличения времени в пути и заканчивая раздражением водителей из-за потерянного времени и слишком большого количества сожженного топлива. Такие сбои в работе наносят ущерб не только водителям, но и всей экономике. Задерживаются товары, нарушается предоставление услуг, поскольку сотрудники приходят на работу с опозданием (и в раздражении).
https://blog.fluxninja.com/blog/traffic-jams-in-the-cloud-unveiling-the-true-enemy-of-reliability
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Притормози! Глубокое погружение в ограничение скорости
В этом посте мы обсудим важность и реализацию механизмов ограничения скорости для повышения надежности API.
Что такое ограничение скорости? Это механизм контроля, определяющий, как часто пользователь может обращаться к вашему API в течение определенного времени.
Итак, почему вас должно волновать ограничение скорости? Рассмотрим ситуацию, когда к вашему API поступает огромное количество запросов за короткий промежуток времени. Это может быть связано с резким увеличением трафика пользователей, сбоем, вызывающим повторные запросы, или даже попыткой перегрузить вашу систему с помощью DDOS-атаки. Без ограничения скорости ваша система может быть перегружена, что приведет к медленным ответам или, что еще хуже, к полному отказу в обслуживании.
Но преимущества ограничения скорости выходят за рамки просто защиты вашей системы. Это также инструмент для управления использованием сервиса. Оно помогает применять политики использования API, контролировать квоты API и даже предлагать клиентам многоуровневые планы использования. Проще говоря, ограничение скорости - это ключевой игрок в эффективном управлении API.
https://www.codereliant.io/rate-limiting-deep-dive/
#devops #девопс
Подпишись 👉@i_DevOps
В этом посте мы обсудим важность и реализацию механизмов ограничения скорости для повышения надежности API.
Что такое ограничение скорости? Это механизм контроля, определяющий, как часто пользователь может обращаться к вашему API в течение определенного времени.
Итак, почему вас должно волновать ограничение скорости? Рассмотрим ситуацию, когда к вашему API поступает огромное количество запросов за короткий промежуток времени. Это может быть связано с резким увеличением трафика пользователей, сбоем, вызывающим повторные запросы, или даже попыткой перегрузить вашу систему с помощью DDOS-атаки. Без ограничения скорости ваша система может быть перегружена, что приведет к медленным ответам или, что еще хуже, к полному отказу в обслуживании.
Но преимущества ограничения скорости выходят за рамки просто защиты вашей системы. Это также инструмент для управления использованием сервиса. Оно помогает применять политики использования API, контролировать квоты API и даже предлагать клиентам многоуровневые планы использования. Проще говоря, ограничение скорости - это ключевой игрок в эффективном управлении API.
https://www.codereliant.io/rate-limiting-deep-dive/
#devops #девопс
Подпишись 👉@i_DevOps
👍6
Faasd
Это переосмысленный OpenFaaS, но без стоимости и сложности Kubernetes. Он работает на одном хосте с очень скромными требованиями, что делает его быстрым и простым в управлении. Под капотом он использует containerd и Container Networking Interface (CNI) вместе с теми же основными компонентами OpenFaaS из основного проекта.
https://github.com/openfaas/faasd
#devops #девопс
Подпишись 👉@i_DevOps
Это переосмысленный OpenFaaS, но без стоимости и сложности Kubernetes. Он работает на одном хосте с очень скромными требованиями, что делает его быстрым и простым в управлении. Под капотом он использует containerd и Container Networking Interface (CNI) вместе с теми же основными компонентами OpenFaaS из основного проекта.
https://github.com/openfaas/faasd
#devops #девопс
Подпишись 👉@i_DevOps
👍4❤2
Devops-exercises
Вопросы для собеседования по DevOps
Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization.
https://github.com/bregman-arie/devops-exercises
#devops #девопс
Подпишись 👉@i_DevOps
Вопросы для собеседования по DevOps
Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization.
https://github.com/bregman-arie/devops-exercises
#devops #девопс
Подпишись 👉@i_DevOps
👍7
Pipeline CI/CD, объясненный простыми словами
Раздел 1 - SDLC с CI/CD
Жизненный цикл разработки программного обеспечения (SDLC) состоит из нескольких ключевых этапов: разработка, тестирование, развертывание и сопровождение. CI/CD автоматизирует и интегрирует эти этапы, чтобы обеспечить более быстрые и надежные релизы.
Когда код размещается в git-репозитории, он запускает автоматизированный процесс сборки и тестирования. Для проверки кода запускаются сквозные (e2e) тесты. Если тесты пройдены, код может быть автоматически развернут на этапе staging/продакшен. Если обнаружены проблемы, код возвращается в разработку для исправления ошибок. Такая автоматизация обеспечивает быструю обратную связь с разработчиками и снижает риск появления ошибок в продакшене.
Раздел 2 - Разница между CI и CD
Непрерывная интеграция (CI) автоматизирует процесс сборки, тестирования и слияния. Она запускает тесты при коммите кода, чтобы обнаружить проблемы интеграции на ранней стадии. Это стимулирует частые коммиты кода и быструю обратную связь.
Continuous Delivery (CD) автоматизирует процессы выпуска, такие как изменение инфраструктуры и развертывание. Она обеспечивает надежный выпуск программного обеспечения в любое время благодаря автоматизированным рабочим процессам. CD также может автоматизировать ручное тестирование и этапы утверждения, необходимые перед развертыванием продакшена.
Раздел 3 - CI/CD Pipeline
Типичный pipeline CI/CD состоит из нескольких взаимосвязанных этапов:
- Разработчик коммитит изменения кода в системе контроля исходного кода
- CI-сервер обнаруживает изменения и запускает сборку
- Код компилируется, тестируется (модульные, интеграционные тесты)
- Результаты тестирования сообщаются разработчику
- При успешном завершении артефакты развертываются в среде staging.
- Дальнейшее тестирование может быть проведено в среде staging перед выпуском.
- Система CD развертывает одобренные изменения в продакшене
#devops #девопс
Подпишись 👉@i_DevOps
Раздел 1 - SDLC с CI/CD
Жизненный цикл разработки программного обеспечения (SDLC) состоит из нескольких ключевых этапов: разработка, тестирование, развертывание и сопровождение. CI/CD автоматизирует и интегрирует эти этапы, чтобы обеспечить более быстрые и надежные релизы.
Когда код размещается в git-репозитории, он запускает автоматизированный процесс сборки и тестирования. Для проверки кода запускаются сквозные (e2e) тесты. Если тесты пройдены, код может быть автоматически развернут на этапе staging/продакшен. Если обнаружены проблемы, код возвращается в разработку для исправления ошибок. Такая автоматизация обеспечивает быструю обратную связь с разработчиками и снижает риск появления ошибок в продакшене.
Раздел 2 - Разница между CI и CD
Непрерывная интеграция (CI) автоматизирует процесс сборки, тестирования и слияния. Она запускает тесты при коммите кода, чтобы обнаружить проблемы интеграции на ранней стадии. Это стимулирует частые коммиты кода и быструю обратную связь.
Continuous Delivery (CD) автоматизирует процессы выпуска, такие как изменение инфраструктуры и развертывание. Она обеспечивает надежный выпуск программного обеспечения в любое время благодаря автоматизированным рабочим процессам. CD также может автоматизировать ручное тестирование и этапы утверждения, необходимые перед развертыванием продакшена.
Раздел 3 - CI/CD Pipeline
Типичный pipeline CI/CD состоит из нескольких взаимосвязанных этапов:
- Разработчик коммитит изменения кода в системе контроля исходного кода
- CI-сервер обнаруживает изменения и запускает сборку
- Код компилируется, тестируется (модульные, интеграционные тесты)
- Результаты тестирования сообщаются разработчику
- При успешном завершении артефакты развертываются в среде staging.
- Дальнейшее тестирование может быть проведено в среде staging перед выпуском.
- Система CD развертывает одобренные изменения в продакшене
#devops #девопс
Подпишись 👉@i_DevOps
👍11❤1
BlazingMQ
Современная высокопроизводительная система очередей сообщений с открытым исходным кодом
BlazingMQ - это фреймворк распределенных очередей сообщений с открытым исходным кодом, который ориентирован на эффективность, надежность и богатый набор функций для современных рабочих процессов.
В основе BlazingMQ лежат долговечные, отказоустойчивые, высокопроизводительные и высокодоступные очереди, а также такие функции, как различные стратегии маршрутизации сообщений (например, рабочие очереди, приоритетные, веерные, широковещательные и т. д.), сжатие, высокая согласованность, обнаружение ядовитых пилюль и т. д.
Очереди сообщений обычно обеспечивают слабосвязанный, асинхронный канал связи ("очередь") между прикладными сервисами (производителями и потребителями), которые отправляют сообщения друг другу. Можно представить это как почтовый ящик для связи между прикладными программами, где "производитель" опускает сообщение в почтовый ящик, а "потребитель" забирает его по своему усмотрению. Сообщения, помещенные в очередь, хранятся до тех пор, пока получатель не получит и не обработает их. Другими словами, приложения-производители и приложения-потребители могут временно и пространственно изолироваться друг от друга, используя очередь сообщений для облегчения взаимодействия.
Внутренняя часть BlazingMQ (брокеры сообщений) была реализована на C++, а клиентские библиотеки доступны на C++, Java и Python.
BlazingMQ - активно развивающийся проект, который был продакшен в Bloomberg в течение 8 с лишним лет.
Этот репозиторий содержит брокер сообщений BlazingMQ, клиентскую библиотеку BlazingMQ C++ и инструмент командной строки BlazingMQ, а клиентскую библиотеку BlazingMQ Java можно найти в этом репозитории.
https://github.com/bloomberg/blazingmq
#devops #девопс
Подпишись 👉@i_DevOps
Современная высокопроизводительная система очередей сообщений с открытым исходным кодом
BlazingMQ - это фреймворк распределенных очередей сообщений с открытым исходным кодом, который ориентирован на эффективность, надежность и богатый набор функций для современных рабочих процессов.
В основе BlazingMQ лежат долговечные, отказоустойчивые, высокопроизводительные и высокодоступные очереди, а также такие функции, как различные стратегии маршрутизации сообщений (например, рабочие очереди, приоритетные, веерные, широковещательные и т. д.), сжатие, высокая согласованность, обнаружение ядовитых пилюль и т. д.
Очереди сообщений обычно обеспечивают слабосвязанный, асинхронный канал связи ("очередь") между прикладными сервисами (производителями и потребителями), которые отправляют сообщения друг другу. Можно представить это как почтовый ящик для связи между прикладными программами, где "производитель" опускает сообщение в почтовый ящик, а "потребитель" забирает его по своему усмотрению. Сообщения, помещенные в очередь, хранятся до тех пор, пока получатель не получит и не обработает их. Другими словами, приложения-производители и приложения-потребители могут временно и пространственно изолироваться друг от друга, используя очередь сообщений для облегчения взаимодействия.
Внутренняя часть BlazingMQ (брокеры сообщений) была реализована на C++, а клиентские библиотеки доступны на C++, Java и Python.
BlazingMQ - активно развивающийся проект, который был продакшен в Bloomberg в течение 8 с лишним лет.
Этот репозиторий содержит брокер сообщений BlazingMQ, клиентскую библиотеку BlazingMQ C++ и инструмент командной строки BlazingMQ, а клиентскую библиотеку BlazingMQ Java можно найти в этом репозитории.
https://github.com/bloomberg/blazingmq
#devops #девопс
Подпишись 👉@i_DevOps
👍1
Создание успешной команды SRE
Успешные приемы, позволяющие вашей команде SRE приносить пользу
Когда я пришел в Mission Lane, я был одним из двух инженеров по надежности сайтов (SRE); вторым был мой начальник, руководитель группы SRE и впоследствии директор организации по платформам. Нам было поручено создать команду SRE, которая занималась бы вопросами наблюдаемости и опыта разработчиков. Это положило начало трехлетнему пути, в ходе которого была создана успешная организация SRE, приносящая огромную пользу Mission Lane. Команда SRE состояла из четырех человек, которые поддерживали 250 микросервисов, 130 разработчиков, сотни релизов в различных средах каждый день и около миллиарда журналов и трассировок каждый день.
https://blog.hans-knecht.com/building-a-successful-sre-team-283232bc2694
#devops #девопс
Подпишись 👉@i_DevOps
Успешные приемы, позволяющие вашей команде SRE приносить пользу
Когда я пришел в Mission Lane, я был одним из двух инженеров по надежности сайтов (SRE); вторым был мой начальник, руководитель группы SRE и впоследствии директор организации по платформам. Нам было поручено создать команду SRE, которая занималась бы вопросами наблюдаемости и опыта разработчиков. Это положило начало трехлетнему пути, в ходе которого была создана успешная организация SRE, приносящая огромную пользу Mission Lane. Команда SRE состояла из четырех человек, которые поддерживали 250 микросервисов, 130 разработчиков, сотни релизов в различных средах каждый день и около миллиарда журналов и трассировок каждый день.
https://blog.hans-knecht.com/building-a-successful-sre-team-283232bc2694
#devops #девопс
Подпишись 👉@i_DevOps
👍6
This media is not supported in your browser
VIEW IN TELEGRAM
TFTUI - The Terraform textual UI
С помощью последней версии вы можете легко визуализировать полное дерево состояний, получая более глубокое представление о текущей конфигурации вашей инфраструктуры. Кроме того, возможность поиска по дереву и просмотра отдельных состояний ресурсов позволяет сосредоточиться на конкретных деталях для более эффективного анализа и управления. Также можно выбрать конкретные ресурсы и выполнить такие действия, как удаление. Наконец, теперь вы можете создавать и применять планы прямо из пользовательского интерфейса.
Ключевые особенности
Комплексное отображение всего дерева состояний Terraform
Удобный просмотр и навигация по состоянию одного ресурса
Поиск по дереву состояний и определениям ресурсов
Создавайте планы, отображайте их в полном объеме и применяйте их непосредственно из интерфейса TUI
Выбор одного/нескольких ресурсов
Операции над ресурсами: восстановление, очистка, удаление, уничтожение
Поддержка Terraform (например, terragrunt)
https://github.com/idoavrah/terraform-tui
#devops #девопс
Подпишись 👉@i_DevOps
С помощью последней версии вы можете легко визуализировать полное дерево состояний, получая более глубокое представление о текущей конфигурации вашей инфраструктуры. Кроме того, возможность поиска по дереву и просмотра отдельных состояний ресурсов позволяет сосредоточиться на конкретных деталях для более эффективного анализа и управления. Также можно выбрать конкретные ресурсы и выполнить такие действия, как удаление. Наконец, теперь вы можете создавать и применять планы прямо из пользовательского интерфейса.
Ключевые особенности
Комплексное отображение всего дерева состояний Terraform
Удобный просмотр и навигация по состоянию одного ресурса
Поиск по дереву состояний и определениям ресурсов
Создавайте планы, отображайте их в полном объеме и применяйте их непосредственно из интерфейса TUI
Выбор одного/нескольких ресурсов
Операции над ресурсами: восстановление, очистка, удаление, уничтожение
Поддержка Terraform (например, terragrunt)
https://github.com/idoavrah/terraform-tui
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Современная безопасность контейнерных приложений
Чем раньше команда задумается о проблеме безопасности, тем лучше. В этой статье обсудим, какие проблемы ИБ есть в стандартном контейнерном приложении, поговорим о безопасности использования Docker, Kubernetes и Terraform и разберём, как можно встроить проверки в стандартный пайплайн деплоя.
Материал написан и дополнен по мотивам выступления Любови Гринкевич и Алексея Миртова из Yandex Cloud на DevOpsConf. Он будет интересен DevOps-инженерам, специалистам по безопасности, владельцам продуктов и всем, кто хочет:
научиться строить безопасный деплой,
автоматизировать проверки безопасности,
понимать проблемы и обсуждать их в команде.
Если вы столкнулись с новыми реалиями и требованиями безопасности и не знаете, с чего начать, эта статья может вам пригодиться. В качестве примеров будем рассматривать продукты и инфраструктуру Yandex Cloud, но большинство рекомендаций универсальны и не привязаны к конкретным сервисам.
https://habr.com/ru/companies/oleg-bunin/articles/786930/
#devops #девопс
Подпишись 👉@i_DevOps
Чем раньше команда задумается о проблеме безопасности, тем лучше. В этой статье обсудим, какие проблемы ИБ есть в стандартном контейнерном приложении, поговорим о безопасности использования Docker, Kubernetes и Terraform и разберём, как можно встроить проверки в стандартный пайплайн деплоя.
Материал написан и дополнен по мотивам выступления Любови Гринкевич и Алексея Миртова из Yandex Cloud на DevOpsConf. Он будет интересен DevOps-инженерам, специалистам по безопасности, владельцам продуктов и всем, кто хочет:
научиться строить безопасный деплой,
автоматизировать проверки безопасности,
понимать проблемы и обсуждать их в команде.
Если вы столкнулись с новыми реалиями и требованиями безопасности и не знаете, с чего начать, эта статья может вам пригодиться. В качестве примеров будем рассматривать продукты и инфраструктуру Yandex Cloud, но большинство рекомендаций универсальны и не привязаны к конкретным сервисам.
https://habr.com/ru/companies/oleg-bunin/articles/786930/
#devops #девопс
Подпишись 👉@i_DevOps
🔥4
Урок, полученный при масштабировании кластера Kubernetes до 1000 подов в AWS EKS
🤔 Почему мы вообще обсуждаем эту тему? Это выглядит как простой случай увеличения количества подов в кластере EKS. Karpenter (должен позаботиться о масштабировании моих узлов) и горизонтальный pod Autoscaler (HPA) и replicaset должны позаботиться о масштабировании pod. Если вы думаете, что это так просто, остановитесь 🛑 здесь. Если вы считаете, что в этой истории есть изюминка, продолжайте читать 📖. На деле все ведет себя не так, как ожидалось, особенно когда мы начинаем выходить за пределы привычного масштаба ⚖️.
https://devopslearning.medium.com/lesson-learned-while-scaling-kubernetes-cluster-to-1000-pods-in-aws-eks-d2d399152bc2
#devops #девопс
Подпишись 👉@i_DevOps
🤔 Почему мы вообще обсуждаем эту тему? Это выглядит как простой случай увеличения количества подов в кластере EKS. Karpenter (должен позаботиться о масштабировании моих узлов) и горизонтальный pod Autoscaler (HPA) и replicaset должны позаботиться о масштабировании pod. Если вы думаете, что это так просто, остановитесь 🛑 здесь. Если вы считаете, что в этой истории есть изюминка, продолжайте читать 📖. На деле все ведет себя не так, как ожидалось, особенно когда мы начинаем выходить за пределы привычного масштаба ⚖️.
https://devopslearning.medium.com/lesson-learned-while-scaling-kubernetes-cluster-to-1000-pods-in-aws-eks-d2d399152bc2
#devops #девопс
Подпишись 👉@i_DevOps
👍3💩1
Сравнение операторов Kubernetes для PostgreSQL. Часть 1
Наши клиенты часто спрашивают нас: "Можем ли мы иметь более дешевую альтернативу Amazon RDS?" или "Было бы здорово иметь что-то похожее на RDS, но не только в AWS...". Чтобы удовлетворить их потребности и реализовать управляемое решение, подобное RDS, в Kubernetes, мы изучили текущее состояние наиболее популярных операторов PostgreSQL: Stolon, Crunchy Data, Zalando, KubeDB, StackGres. Мы сравнили их и сделали свой выбор.
Но прежде чем анализировать, что мы имеем в мире операторов K8s для PgSQL, давайте определим общие требования к потенциальной замене Amazon RDS...
https://blog.palark.com/comparing-kubernetes-operators-for-postgresql/
Сравнение операторов Kubernetes для PostgreSQL. Часть 2: CloudNativePG
Эта статья является продолжением нашего цикла статей об операторах PostgreSQL Kubernetes. В прошлой части мы сравнили операторы Stolon, Crunchy Data, Zalando, KubeDB и StackGres. Мы быстро рассмотрели их и свели их возможности в сравнительную таблицу. В этой части мы расскажем о CloudNativePG, его функциях и возможностях, а также обновим наше сравнение, включив в него новый оператор.
https://blog.palark.com/cloudnativepg-and-other-kubernetes-operators-for-postgresql/
#devops #девопс
Подпишись 👉@i_DevOps
Наши клиенты часто спрашивают нас: "Можем ли мы иметь более дешевую альтернативу Amazon RDS?" или "Было бы здорово иметь что-то похожее на RDS, но не только в AWS...". Чтобы удовлетворить их потребности и реализовать управляемое решение, подобное RDS, в Kubernetes, мы изучили текущее состояние наиболее популярных операторов PostgreSQL: Stolon, Crunchy Data, Zalando, KubeDB, StackGres. Мы сравнили их и сделали свой выбор.
Но прежде чем анализировать, что мы имеем в мире операторов K8s для PgSQL, давайте определим общие требования к потенциальной замене Amazon RDS...
https://blog.palark.com/comparing-kubernetes-operators-for-postgresql/
Сравнение операторов Kubernetes для PostgreSQL. Часть 2: CloudNativePG
Эта статья является продолжением нашего цикла статей об операторах PostgreSQL Kubernetes. В прошлой части мы сравнили операторы Stolon, Crunchy Data, Zalando, KubeDB и StackGres. Мы быстро рассмотрели их и свели их возможности в сравнительную таблицу. В этой части мы расскажем о CloudNativePG, его функциях и возможностях, а также обновим наше сравнение, включив в него новый оператор.
https://blog.palark.com/cloudnativepg-and-other-kubernetes-operators-for-postgresql/
#devops #девопс
Подпишись 👉@i_DevOps
👍8
Как разработчику «влиться» в тему DevOps
Сегодня мы решили взглянуть на ситуацию с Java- и Python-разработчиком, который задумался о «погружении» в тему DevOps в тот момент, когда он начал все больше отдаляться от привычных инструментов в пользу работы с Oracle Weblogic и shell-скриптами. Он решил совместить свой опыт в области разработки с новым опытом в работе с процессами.
Мы посмотрели на основные советы экспертов в области DevOps на Quora и дополнили рассказ примерами из опыта команды 1cloud.
https://habr.com/ru/companies/1cloud/articles/277369/
#devops #девопс
Подпишись 👉@i_DevOps
Сегодня мы решили взглянуть на ситуацию с Java- и Python-разработчиком, который задумался о «погружении» в тему DevOps в тот момент, когда он начал все больше отдаляться от привычных инструментов в пользу работы с Oracle Weblogic и shell-скриптами. Он решил совместить свой опыт в области разработки с новым опытом в работе с процессами.
Мы посмотрели на основные советы экспертов в области DevOps на Quora и дополнили рассказ примерами из опыта команды 1cloud.
https://habr.com/ru/companies/1cloud/articles/277369/
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Kyverno
Управление нативными политиками Kubernetes
Kyverno - это движок политик, разработанный для инженерных команд платформы Kubernetes. Он обеспечивает безопасность, автоматизацию, соответствие и управление с помощью политик как кода. Kyverno может проверять, изменять, генерировать и очищать конфигурации с помощью средств контроля допуска Kubernetes, фонового сканирования и сканирования репозитория исходного кода. Политики Kyverno могут управляться как ресурсы Kubernetes и не требуют изучения нового языка. Kyverno спроектирован таким образом, чтобы хорошо работать с уже используемыми вами инструментами, такими как kubectl, kustomize и Git.
https://github.com/kyverno/kyverno
#devops #девопс
Подпишись 👉@i_DevOps
Управление нативными политиками Kubernetes
Kyverno - это движок политик, разработанный для инженерных команд платформы Kubernetes. Он обеспечивает безопасность, автоматизацию, соответствие и управление с помощью политик как кода. Kyverno может проверять, изменять, генерировать и очищать конфигурации с помощью средств контроля допуска Kubernetes, фонового сканирования и сканирования репозитория исходного кода. Политики Kyverno могут управляться как ресурсы Kubernetes и не требуют изучения нового языка. Kyverno спроектирован таким образом, чтобы хорошо работать с уже используемыми вами инструментами, такими как kubectl, kustomize и Git.
https://github.com/kyverno/kyverno
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Constellation
Это первый конфиденциальный Kubernetes. Constellation защищает целые кластеры Kubernetes от (облачной) инфраструктуры с помощью конфиденциальных вычислений.
Constellation - это движок Kubernetes, который призван обеспечить максимальную безопасность данных. Он оборачивает ваш кластер K8s в единый конфиденциальный контекст, защищенный от базовой облачной инфраструктуры. Все внутри всегда зашифровано, в том числе во время выполнения в памяти. Для этого Constellation использует конфиденциальные вычисления (см. технический обзор) и, в частности, конфиденциальные виртуальные машины.
С точки зрения безопасности Constellation разработан таким образом, чтобы все данные всегда были зашифрованы и чтобы предотвратить доступ с уровня инфраструктуры (т. е. удалить инфраструктуру из TCB). Это включает доступ сотрудников ЦОД, привилегированных администраторов облака и злоумышленников, проникающих через инфраструктуру (например, злонамеренных соарендаторов, повышающих свои привилегии).
С точки зрения DevOps, Constellation спроектирован так, как вы ожидаете от современного движка K8s.
https://github.com/edgelesssys/constellation
#devops #девопс
Подпишись 👉@i_DevOps
Это первый конфиденциальный Kubernetes. Constellation защищает целые кластеры Kubernetes от (облачной) инфраструктуры с помощью конфиденциальных вычислений.
Constellation - это движок Kubernetes, который призван обеспечить максимальную безопасность данных. Он оборачивает ваш кластер K8s в единый конфиденциальный контекст, защищенный от базовой облачной инфраструктуры. Все внутри всегда зашифровано, в том числе во время выполнения в памяти. Для этого Constellation использует конфиденциальные вычисления (см. технический обзор) и, в частности, конфиденциальные виртуальные машины.
С точки зрения безопасности Constellation разработан таким образом, чтобы все данные всегда были зашифрованы и чтобы предотвратить доступ с уровня инфраструктуры (т. е. удалить инфраструктуру из TCB). Это включает доступ сотрудников ЦОД, привилегированных администраторов облака и злоумышленников, проникающих через инфраструктуру (например, злонамеренных соарендаторов, повышающих свои привилегии).
С точки зрения DevOps, Constellation спроектирован так, как вы ожидаете от современного движка K8s.
https://github.com/edgelesssys/constellation
#devops #девопс
Подпишись 👉@i_DevOps
👍4
This media is not supported in your browser
VIEW IN TELEGRAM
Service-Hub
JovianX Service Hub - это инструмент, обеспечивающий самообслуживание для внутренних заинтересованных сторон. Он предоставляет каталог инфраструктурных сервисов по требованию (например, базы данных, s3 buckets, выполнение рабочих процессов Airflow, сервисы с предварительно настроенными или предварительно загруженными наборами данных и т. д.) через простой пользовательский интерфейс самообслуживания и CLI.
https://github.com/JovianX/Service-Hub
#devops #девопс
Подпишись 👉@i_DevOps
JovianX Service Hub - это инструмент, обеспечивающий самообслуживание для внутренних заинтересованных сторон. Он предоставляет каталог инфраструктурных сервисов по требованию (например, базы данных, s3 buckets, выполнение рабочих процессов Airflow, сервисы с предварительно настроенными или предварительно загруженными наборами данных и т. д.) через простой пользовательский интерфейс самообслуживания и CLI.
https://github.com/JovianX/Service-Hub
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Argocd-vault-replacer
Плагин для ArgoCD - прекрасный плагин для замены placeholders в манифестах Kubernetes на секреты, хранящиеся в Hashicorp Vault. Двоичный файл рекурсивно просканирует текущую директорию на наличие файлов .yaml (или .yml, если вы так захотите), или возьмет yaml из stdin, и попытается заменить строки вида <secret:/store/data/path~key> на те, что получены из хранилища Vault kv2.
В этом сценарии он может постобработать вывод другого инструмента, например Kustomize или Helm.
Раньше этот плагин был доступен как прямой плагин к ArgoCD, но он не был адаптирован к потребностям ArgoCD 2.7 в работе в качестве sidecar. Если у вас есть такая потребность, пожалуйста, поднимите вопрос.
Примечание: Эта и предыдущие версии этого плагина работают только с vault, поэтому secret:... может быть указан как vault:..... В планах на будущее могут появиться и другие провайдеры секретов.
https://github.com/crumbhole/argocd-vault-replacer
#devops #девопс
Подпишись 👉@i_DevOps
Плагин для ArgoCD - прекрасный плагин для замены placeholders в манифестах Kubernetes на секреты, хранящиеся в Hashicorp Vault. Двоичный файл рекурсивно просканирует текущую директорию на наличие файлов .yaml (или .yml, если вы так захотите), или возьмет yaml из stdin, и попытается заменить строки вида <secret:/store/data/path~key> на те, что получены из хранилища Vault kv2.
В этом сценарии он может постобработать вывод другого инструмента, например Kustomize или Helm.
Раньше этот плагин был доступен как прямой плагин к ArgoCD, но он не был адаптирован к потребностям ArgoCD 2.7 в работе в качестве sidecar. Если у вас есть такая потребность, пожалуйста, поднимите вопрос.
Примечание: Эта и предыдущие версии этого плагина работают только с vault, поэтому secret:... может быть указан как vault:..... В планах на будущее могут появиться и другие провайдеры секретов.
https://github.com/crumbhole/argocd-vault-replacer
#devops #девопс
Подпишись 👉@i_DevOps
👍2
Код для облака: Освоение DevOps с помощью Python, Terraform и Kubernetes на AWS
Как инженер DevOps, я обычно связан с конвейерами, автоматизацией и облачными сервисами. Однако мне всегда было интересно узнать о другой стороне технологического мира - разработке приложений. Поэтому я подумал, почему бы не разнообразить мир? Так я пришел к созданию финансового приложения на Python, дополненного REST API.
В этом блоге я рассказываю о разработке и развертывании моего финансового приложения с нуля, от кода начального приложения до его развертывания на AWS с помощью Docker, Kubernetes (EKS), Terraform и Ansible. И знаете что? Я автоматизировал весь процесс - каждый его кусочек!
https://medium.com/@sophnel/coding-to-cloud-mastering-devops-with-python-terraform-and-kubernetes-on-aws-6251a910511f
#devops #девопс
Подпишись 👉@i_DevOps
Как инженер DevOps, я обычно связан с конвейерами, автоматизацией и облачными сервисами. Однако мне всегда было интересно узнать о другой стороне технологического мира - разработке приложений. Поэтому я подумал, почему бы не разнообразить мир? Так я пришел к созданию финансового приложения на Python, дополненного REST API.
В этом блоге я рассказываю о разработке и развертывании моего финансового приложения с нуля, от кода начального приложения до его развертывания на AWS с помощью Docker, Kubernetes (EKS), Terraform и Ansible. И знаете что? Я автоматизировал весь процесс - каждый его кусочек!
https://medium.com/@sophnel/coding-to-cloud-mastering-devops-with-python-terraform-and-kubernetes-on-aws-6251a910511f
#devops #девопс
Подпишись 👉@i_DevOps
🔥6👍2🫡1