deployctl

a new gitlab runner for publishing static content ranging from webpages, release based content, RPM and debian repositories straight from gitlab with out of the box automatic https and no hassle to setup keys and or passwords for publishing.

Intro

Using Gitlab and the integrated CI/CD for software and webpages is a great way to keep track of things and manage the projects, it being opensource and out of the box support for CI/CD makes it a must have tool in software development.

With this project we hope to add even more or easier deployment of output and/or static webpages.

Easy deployment of environments for publishing software releases, repository setup and deployment for rpm/deb and static web page development from a Gitlab-instance (gitlab.com and/or private instance).

• No ssh-key’s needed
• multiple sites and environments on a deploy-server
• Simple configuration, straight from the gitlab-ci.yml
• run once the setup on a server with a domain-name and a wild-card DNS entry.
• tag’s and release notes for releases

Read more on the choice to integrate the runner with deployctl deployctl runner

Overview

All deployctl commands are predefined commands executed by the deployctl runner which is running on the deployment/production web-server as a non-privileged user.

so for dynamic environments :

• add the runner-tag to the deployment in the .gitlab-ci.yml file,
• add the runner to the project
• define a minimum set of variables

and deployctl handles:

• moving the content in place
• and/or generate the download pages and release-tags,
• configure the webserver
• generate certificates
• reloading the webserver (nginx) etc.

As a quick example, an excerpt of the gitlab-ci.yml to publish this website.

variables:
  CI_PROJECT_PATH_SLUG: deployctl-www-deployctl-com
  DEPLOY_DOMAIN_APP: gioxapp.com
  DEPLOY_DOMAIN : www.deployctl.com
  DEPLOY_CONFIG_HTTPS: "True"
  DEPLOY_PUBLISH_PATH: '["/":"/web/_sites/"]'

release:
  tags:
    - deployctl-gioxapp.com
  variables:
    GIT_STRATEGY: none
  environment:
    name: production
    url: http://$DEPLOY_DOMAIN
  script:
    - deployctl static
  only:
    - master

deployctl static will :

1. copy the content generated from previous stage in the /web/sites/ directory
2. setup the website configuration
3. verify the website
4. and depending on DEPLOY_CONFIG_HTTPS configure the website for https

Remark:

1. make sure the DEPLOY_DOMAIN_APP points to the app-server
2. make sure the DEPLOY_DOMAIN has a CNAME record pointing to $DEPLOY_DOMAIN_APP
3. CI_PROJECT_PATH_SLUG needs to be defined only if no custom domain in DEPLOY_DOMAIN is defined. Since gitlab 9.3, this is defined, but it can contain _ making it a no go to use as part of a domain name since let’s encrypt does not accept _. gitlab issue #34643
4. Optional define DEPLOY_PUBLISH_PATH: '["/":"/web/_sites/"]' which will use the content in /web/_sites/ as output, no need to copy or move content.
5. if DEPLOY_PUBLISH_PATH is not defined, it defaults to /public/

deployctl commands:

1. deployctl static : deploys a static page for the environment from the public directory

2. deployctl release : creates a download page per environment with:

• list of download-links to the content of the release.

• links list generated from:

  1. *.url files, containing <href>,metric, with filename without extension as name.

  2. DEPLOY_hrefs: a key/value array: ‘[“name”: “href”,”name1”: “href2”,…]’

• And For a production environment, with release tag creates additional :

  • Release notes as per the Gitlab tag’s release.

  • updates the releases page, with all releases

  • updates /release.json : a static JSON database, containing an overview of all releases with release notes as per gitlab Tag’s, links and other info.

  • updates /release_json.js : a javascript containing all the release data.

  • updates <tag>/release_json.js : a javascript containing the release data.

  • updates /tag.svg : a release tag to use in the projectpage or webpage indicating the latest release.

  • an updated link to /latest

1. deployctl delete : deletes the deployment environment

2. deployctl repo_conf Configures a repository Setup a repository
3. deployctl repo_add adds packages to a repository Deploy to repository

REMARK: Release info is only availleble when the project is public! If you like this, upvote gitlab issue #29566

LET’S GIVE IT A SPIN

• Spin of a VM on a provider, give it a hostname.

• have the DNS A/AAAA record to point to it’s ip.

• add a wild-card * CNAME record.

• Take note of the gitlab runner registration-token and url on gitlab.

• Run the setup, see setup to:
  • register the runner on a gitlab instance.
  • install nginx as web-server
  • setup deployctl runner.
• On gitlab create a project, use a template from our blog:
  • for a release
    • example release
    • heloworld_c
  • for a static webpage:
    • example static.
    • this webpage).
  • to create a repository or push to repo:
    • repository deployment.
    • heloworld_c

• Modify the repository

• For the production environment, choose a domain, add a DNS record CNAME pointing to the hostname of the deployment server, or comment the variable DEPLOY_DOMAIN to use: production.${DEPLOY_PROJECT_NAME_SLUG}.${DEPLOY_DOMAIN_APP}

Read more about gitlab support and concepts for dynamic environment deployment here

---

---