На данный момент облачные CI-системы — очень востребованный сервис. В этой статье мы расскажем, как, с помощью уже существующих средств, доступных в PVS-Studio, можно интегрировать анализ исходного кода с облачной CI платформой, на примере сервиса Travis CI.
At the moment, cloud CI systems are a highly-demanded service. In this article, we'll tell you how to integrate analysis of source code into a CI cloud platform with the tools that are already available in PVS-Studio. As an example we'll use the Travis CI service.
Несмотря на то, что большая часть ИТ-индустрии внедряет инфраструктурные решения на базе контейнеров и облачных решений, необходимо понимать и ограничения этих технологий. Традиционно Docker, Linux Containers (LXC) и Rocket (rkt) не являются по-настоящему изолированными, поскольку в своей работе они совместно используют ядро родительской операционной системы. Да, они эффективны с точки зрения ресурсов, но общее количество предполагаемых векторов атаки и потенциальные потери от взлома все еще велики, особенно в случае мультиарендной облачной среды, в которой размещаются контейнеры.
Корень нашей проблемы заключается в слабом разграничении контейнеров в моменте, когда операционная система хоста создает виртуальную область пользователя для каждого из них. Да, были проведены исследования и разработки, направленные на создание настоящих «контейнеров» с полноценной «песочницей». И большинство полученных решений ведут к перестройке границ между контейнерами для усиления их изоляции. В этой статье мы рассмотрим четыре уникальных проекта от IBM, Google, Amazon и OpenStack соответственно, в которых используются разные методы для достижения одной и той же цели: создания надежной изоляции. Так, IBM Nabla разворачивает контейнеры поверх Unikernel, Google gVisor создает специализированное гостевое ядро, Amazon Firecracker использует чрезвычайно легкий гипервизор для приложений песочницы, а OpenStack помещает контейнеры в специализированную виртуальную машину, оптимизированную для инструментов оркестрации.
Читать полностью »
24.06 в 10:30 UTC в интернете случился коллапс: на небольшую компанию на севере Пенсильвании хлынул поток трафика из множества маршрутов, проходящих через крупного провайдера Verizon (AS701), — с тем же успехом навигатор мог бы отправить поток машин с многополосного шоссе на узкую улочку. В результате у многих веб-сайтов на Cloudflare и многих других провайдеров возникли проблемы с доступом. Этого вообще не должно было произойти, ведь Verizon не должен был рассылать эти маршруты всему интернету. Чтобы узнать, как так вышло, читайте дальше.
Есть разные подходы к обновлению PostgreSQL, но некоторые приводят к простою приложения. Если нужно избежать простоя, используйте для обновления репликацию — логическую или физическую (потоковую), в зависимости от сценария. В этой статье мы рассмотрим разницу между логической и физической репликацией в PostgreSQL. Затем подробно поговорим, как обновить версию с помощью логической репликации и при этом избежать простоя приложения. В следующей статье обсудим репликацию физическую.
В предыдущих статьях мы уже говорили о методах обновления PostgreSQL (Обновление версии PostgreSQL с помощью pg_dumpall и Обновление версии PostgreSQL с помощью pg_dump/pg_restore) в рамках серии Обновление или миграция старых версий PostgreSQL в новые. Но оба этих метода не исключают простоя.
В статье я расскажу, как мы подошли к вопросу отказоустойчивости PostgreSQL, почему это стало для нас важно и что в итоге получилось.
У нас высоконагруженный сервис: 2,5 млн пользователей по всему миру, 50К+ активных пользователей каждый день. Сервера находятся в Amazone в одном регионе Ирландии: в работе постоянно 100+ различных серверов, из них почти 50 — с базами данных.
Весь backend — большое монолитное stateful-приложение на Java, которое держит постоянное websocket соединение с клиентом. При одновременной работе нескольких пользователей на одной доске все они видят изменения в режиме реального времени, потому что каждое изменение мы записываем в базу. У нас примерно 10К запросов в секунду к нашим базам. В пиковой нагрузке в Redis мы пишем по 80-100К запросов в секунду.
Читать полностью »
Кажется, мне довелось сделать десятки презентаций для коллег, заказчиков и публичных выступлений за мою карьеру в IT. Многие годы Powerpoint как средство изготовления слайдов оставался для меня естественным и надёжным выбором. Но в этом году ситуация качественно изменилась. С февраля по май мне довелось выступить на пяти конференциях, и слайды к докладам надо было готовить в сжатые сроки, но качественно. Встал вопрос о делегировании той части работы, что касается визуального дизайна слайдов, другим людям. Как-то раз я попытался работать с дизайнером, пересылая файлы .pptx по почте, но работа превратилась в хаос: никто не знал, какая версия слайдов «самая новая», а вёрстка «ехала» по причине различия версий Powerpoint и шрифтов на наших машинах. И я решил попробовать что-то новое. Попробовал, и с тех пор не думаю возвращаться к Powerpoint.
Прим. перев.: В сообществе Kubernetes явную популярность набирает тренд под названием GitOps, в чём мы лично убедились, посетив KubeCon Europe 2019. Этот термин был относительно недавно придуман главой компании Weaveworks — Alexis Richardson — и означает применение привычных для разработчиков инструментов (в первую очередь — Git, откуда и само название) для решения задач эксплуатации. В частности, речь об эксплуатации Kubernetes через хранение его конфигураций в Git и автоматического выката изменений в кластер. О двух подходах к этому выкату и рассказывает Matthias Jg в данной статье.
В прошлом году (на самом деле, формально это произошло в августе 2017 г. — прим. перев.) появился новый подход к развёртыванию приложений в Kubernetes. Он называется GitOps, а в его основе лежит базовое представление о том, что отслеживание версий deployment'ов ведется в безопасной среде Git-репозитория.Читать полностью »
Kubernetes быстро стал стандартом для поставок и масштабирования контейнерных приложений и управления ими. Это очень гибкое и универсальное решение с открытым исходным кодом. У него обширная документация, и в ней не всегда легко найти нужный раздел. Поэтому Kubernetes так непросто освоить. После планирования кластера его еще нужно установить, а тут тоже не все гладко. Поэтому и существуют инструменты развертывания, вроде Kubespray, которые упрощают работу. Я расскажу об автоматическом развертывании кластера Kubernetes с помощью Kubespray в облаке OpenStack (Open Telekom Cloud).
25 апреля мы в Mail.ru Group провели конференцию про облака и вокруг — mailto:CLOUD. Несколько хайлайтов:
Все видео с конференции mailto:CLOUD можно посмотреть по ссылке, а здесь можно почитать, как прошла дискуссия про микросервисы. Своими — успешными — кейсами избавления от монолитов поделились Александр Деулин, руководитель центра исследования и разработки бизнес-систем «МегаФона», и Сергей Сергеев, директор по информационным технологиям группы «М.Видео-Эльдорадо». Также обсудили близкие вопросы IT-стратегии, процессов и даже HR.
Читать полностью »
