Последние публикации

GitLab CI предоставляет удобную возможность сохранения артефактов сборок в GitLab. Артефакт - любой файл, который разработчик хочет сохранить на продолжительное время после сборки. Данная возможность может использоваться для хранения дистрибутивов и различных журналов сборок. Использовать артефакты очень просто. В статье разберем как это реализовано на примере публикации собранного DEB пакета, который позже возможно скачать из GitLab.

Артефакты GitLab CI не всегда являются самым удобным средством, иногда вам может потребоваться подключить FTP, SFTP, публикацию в Nexus или другие системы хранения артефактов, однако, часто достаточно просто иметь хранилище, которое позволит просто получить доступ к результату сборки.

5 сентября 2018 мы выпустили первый релиз нового расширения для CloudStack, которое предназначено для автоматического выделения неуправляемых частных сетей для аккаунтов и проектов CloudStack. Расширение предназначено только для использования с облаками, работающими под управлением гипервизора KVM. После установки, каждая виртуальная машина в аккаунте получает дополнительную сетевую карту VirtIO, которая относится к частной сети доступной только для машин, создаваемых в рамках аккаунта.

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

Публикация кода в открытые репозитории Git. Допустим, вы разрабатываете продукт и какие-то его ветки должны быть доступны для сообщества или вы, в принципе, разрабатываете продукт с открытым кодом, но ведете разработку в GitLab, выполняете тестирование и доставку с помощью GitLab CI. Обычно вы хотите, чтобы пользователи имели возможность постоянного доступа к исходному коду продукта, поэтому хотите выкладывать его на GitHub или BitBucket.

Публикация кода в репозиторий клиента. Вы разрабатываете программный продукт для одного или более клиентов, а при создании релизов публикуете исходный код на их внутренние GitLab серверы, на которых для релизного кода отрабатывают соответствующие процедуры CI/CD и выполняется развертывание кода в продуктовую или ‘staging’ среду. При этом, вы можете хотеть публиковать разным клиентам разные ветки репозитория, которые содержат специализированные модификации.

Ранее мы уже писали о DC/OS – унифицированной распределённой платформе для оркестрации приложений. Она позволяет за минуты развернуть из каталога готовых решений (DC/OS Universe) такие системы как Apache Spark, Apache Kafka, Apache Cassandra, HDFS, Elasticsearch, NGINX, OpenVPN и другие. Ключевым элементом системы является кластерный менеджер Mesos. В качестве фреймворка для оркестрации поставляется Marathon. После того, как система стала доступной как open-source, интерес к ней значительно возрос.

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

• типы логических сетей в СloudStack;
• модели сетевого взаимодействия;
• требования к конфигурациям сетей;
• требования к физическим соединениям.

Для того, чтобы статья была понятна новичкам, местами мы будем прибегать к упрощениям, которые в 95% случаев являются истинными. Также, говоря о сетевой изоляции, мы будем подразумевать VLAN, но более опытные пользователи могут также использовать технологии SDN.

Эта статья является переводом и адаптацией англоязычного материала. Оригинал статьи написан Paul Angus из ShapeBlue. С исходной статьей можно ознакомиться на сайте ShapeBlue.