All Projects → StackStorm → st2-packages

StackStorm / st2-packages

Licence: other
StackStorm deb/rpm packages (automated docker build pipeline)

Programming Languages

shell
77523 projects
ruby
36898 projects - #4 most used programming language
python
139335 projects - #7 most used programming language
Makefile
30231 projects

Projects that are alternatives of or similar to st2-packages

Goreleaser
Deliver Go binaries as fast and easily as possible
Stars: ✭ 9,290 (+37060%)
Mutual labels:  deb, rpm
Boostnote-packages
Repo containing .rpm, .deb and Boostnote app folder
Stars: ✭ 31 (+24%)
Mutual labels:  deb, rpm
Rakudo Pkg
Pre-compiled OS packages for Rakudo
Stars: ✭ 55 (+120%)
Mutual labels:  deb, rpm
Javapackager
📦 Gradle/Maven plugin to package Java applications as native Windows, Mac OS X, or GNU/Linux executables and create installers for them.
Stars: ✭ 285 (+1040%)
Mutual labels:  deb, rpm
Electron Builder
A complete solution to package and build a ready for distribution Electron app with “auto update” support out of the box
Stars: ✭ 11,653 (+46512%)
Mutual labels:  deb, rpm
Platform Install Packages
Official deployment packages to install the Kaltura platform on a server or cluster environments using native OS package managers
Stars: ✭ 436 (+1644%)
Mutual labels:  deb, rpm
Fpm Within Docker
Leverage fpm inside pre-baked docker images in order to build and test native DEB and RPM packages.
Stars: ✭ 80 (+220%)
Mutual labels:  deb, rpm
foreman-packaging
Packaging files (RPMs, debs) for Foreman and its dependencies
Stars: ✭ 38 (+52%)
Mutual labels:  deb, rpm
Redishappy
Redis Sentinel high availabillity daemon
Stars: ✭ 111 (+344%)
Mutual labels:  deb, rpm
Docker Ce Packaging
Packaging scripts for Docker CE
Stars: ✭ 111 (+344%)
Mutual labels:  deb, rpm
Jenkins Bootstrap Shared
Jenkins as immutable infrastructure made easy. A repository of shared scripts meant to be used as a git submodule. Packing Jenkins, plugins, and scripts into immutable packages and images.
Stars: ✭ 270 (+980%)
Mutual labels:  deb, rpm
puppet-st2
Puppet Module to install and configure StackStorm, IFTTT for Ops
Stars: ✭ 20 (-20%)
Mutual labels:  stackstorm, st2
SetupBuilder
Gradle plugin for building setups for different platforms.
Stars: ✭ 75 (+200%)
Mutual labels:  deb, rpm
Open Build Service
Build and distribute Linux packages from sources in an automatic, consistent and reproducible way #obs
Stars: ✭ 599 (+2296%)
Mutual labels:  deb, rpm
package-build
A toolset for building system packages using Docker and fpm-cookery
Stars: ✭ 36 (+44%)
Mutual labels:  deb, rpm
Nfpm
NFPM is Not FPM - a simple deb, rpm and apk packager written in Go
Stars: ✭ 1,088 (+4252%)
Mutual labels:  deb, rpm
St2
StackStorm (aka "IFTTT for Ops") is event-driven automation for auto-remediation, security responses, troubleshooting, deployments, and more. Includes rules engine, workflow, 160 integration packs with 6000+ actions (see https://exchange.stackstorm.org) and ChatOps. Installer at https://docs.stackstorm.com/install/index.html. Questions? https://…
Stars: ✭ 4,600 (+18300%)
Mutual labels:  stackstorm, st2
LAMPP-Manager
A simple LAMPP manager designed to automate all the work.
Stars: ✭ 117 (+368%)
Mutual labels:  deb, rpm
Sbt Native Packager
sbt Native Packager
Stars: ✭ 1,480 (+5820%)
Mutual labels:  deb, rpm
Aliddns
aliyun ddns for golang【阿里云DDNS服务,用来将自己的动态IP同步到自己的域名解析服务器,安装方便,配置简单,默认支持Linux和MacOS以后台服务方式持续运行】
Stars: ✭ 136 (+444%)
Mutual labels:  deb, rpm

Stackstorm packages build environment

Circle CI Build Status Go to Docker Hub Download deb/rpm

Highlights

  • Docker based. Leveraging docker it's possible to deliver packages for any OS distro in a fast and reliable way.
  • Rake + sshkit-based execution enables easy configuration via simple DSL and brings parallel task processing out of the box.
  • Test-driven workflow. Artifacts built are not only available for any enabled OS distro but at the same time tested on a bunch of platforms, providing feedback such as can be installed, services can start up, operations can be executed etc.

Overview

Packages build environment is a multi-container docker application defined and managed with docker-compose. It consists of four types of containers:

  • Packaging runner (https://quay.io/stackstorm/packagingrunner) - the main entry point, package build and test processing controller container.
  • Packaging build (https://hub.docker.com/r/stackstorm/packagingbuild/) - container where actual .deb/.rpm artifacts build takes place. It's used to bring up the build environment specific for OS distro. This means that different containers are available such as packagingbuild:centos7, packagingbuild:focal correspondingly for CentOS 7 and Ubuntu Focal.
  • Packaging test (https://hub.docker.com/r/stackstorm/packagingtest/) - containers where built artifacts are tested, i.e. artifacts are installed, configuration is written and tests are performed.
  • Services - these are different containers required for testing such as rabbitmq and mongodb

Dockerfiles sources are available at StackStorm/st2-dockerfiles.

The Packages build environment compose application brings a self-sufficient pipeline to deliver ready to use packages.

Usage

It's very simple to invoke the whole build-test pipeline. First just make sure that docker-compose.yml has your distro specification, after that issue the following commands:

# (Optional) First clean out previous build containers
docker-compose kill
docker-compose rm -f

# To build packages for ubuntu focal (--rm will wipe packaging runner container. All others will remain active).
docker-compose run --rm focal

Execution takes a while, so grab a cup of tea or coffee and wait until it finishes. When build and test processes succeed, you'll find the StackStorm packages in /tmp/st2-packages on your host machine:

ls -l1 | grep ".deb$"
-rw-r--r-- 1 root root 30872652 Feb  9 18:32 st2_1.4dev-1_amd64.deb

Manual testing inside the docker environment

After the build and test stages are finished all docker containers remain active, so you are welcome to do more in-depth testing if desired. To do so simply run:

docker ps
# Find the required testing container
# In our case it will be st2packages_focaltest_1

# Simply exec to docker
docker exec -it st2packages_focaltest_1 bash

Once done, you are inside the testing environment where all services are up and running. Don't forget to do (after exec):

export TERM=xterm

At this point you can do any manual testing which is required.

Vagrant based build and test

In order to build, package, install and test ST2 in an isolated Vagrant VM, run the following:

vagrant up $TARGET

Where $TARGET is one of bionic, focal, el7, or el8. If you are using el8, comment out the vm_config.vm.provision :docker line in the Vagrantfile. There is logic in setup-vagrant.sh to install docker in el8.

The following steps are run while provisioning the Vagrant VM:

  1. Install docker and docker-compose.
  2. Run docker-compose run --rm $TARGET to build, test and package ST2 as described in prior sections.
  3. Install the packages built in step 2, unless the host $ST2_INSTALL environment variable is set to a value other than yes.
  4. Execute the st2-self-check script, unless the host $ST2_VERIFY environment variable is set to a value other than yes.

As currently implemented, it is not possible to bypass steps 1 and 2. In the future, we may want to consider allowing the host to provide existing ST2 packages, and install/self-check those in the Vagrant VM.

To specify the ST2 source URL and REV (i.e., branch), use ST2_GITURL and ST2_GITREV environment variables on the host prior to provisioning the VM.

Prior to running st2-self-check, the required auth token is generated using st2 auth. If necessary, you can change the default username and password passed to st2 auth. To do this, set the ST2USER and ST2PASSWORD environment variables on the host prior to provisioning the VM. The default values are st2admin and Ch@ngeMe respectively.

Installation

Current community packages are hosted on https://packagecloud.io/StackStorm. For detailed instructions how install st2 and perform basic configuration follow these instructions:

Adding Support For a New Distribution

If you are adding support for a new distribution for which packagingbuild and packagingtest images are not yet published to Docker Hub and you want to test the build pipeline locally, you need to update docker-compose.yml file to use locally built Docker images.

For example:

...

bionic:
  ...
  image: quay.io/stackstorm/packagingrunner
  ...
...

bionicbuild:
  ...
  image: bionicbuild
  ...

...

bionictest:
  ...
  image: bionictest
  ...

NOTE: Main distro definition (e.g. bionic, focal, etc.) needs to use packaging runner image.

As you can see, image attribute references local image tagged bionicbuild instead of a remote image (e.g. stackstorm/packagingbuild:bionic or similar).

Before that will work, you of course also need to build those images locally.

For example:

cd ~/st2packaging-dockerfiles/packagingbuild/bionic
docker build -t bionicbuild .

cd ~/st2packaging-dockerfiles/packagingtest/bionic/systemd
docker build -t bionictest .

License and Authors

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].