Forge Home

Modules

Puppet

Resources

PuppetEcosystemPuppet CommunityUpdates

application

Tooling for Continuous Delivery (CD) of applications in a Puppet managed environment by leveraging orchestration through Bolt or Choria.
Project URLRSS FeedReport issues

2,196 downloads

18 latest version

3.1 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 4.1.0 (latest)
  • 4.0.1
  • 4.0.0
  • 3.0.0
  • 2.0.0
  • 1.2.0
  • 1.1.0
  • 1.0.1
  • 1.0.0
released Nov 13th 2024
This version is compatible with:
  • Puppet Enterprise 2023.8.x, 2023.7.x, 2023.6.x, 2023.5.x, 2023.4.x, 2023.3.x, 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x
  • Puppet >= 7.16.0 < 9.0.0
  • ,
Tasks:
  • activate
  • deploy
  • list
  • prune
  • remove

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'opuscodium-application', '4.1.0'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add opuscodium-application
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install opuscodium-application --version 4.1.0

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Download

Documentation

opuscodium/application — version 4.1.0 Nov 13th 2024

application

Build Status Puppet Forge Puppet Forge - downloads Puppet Forge - endorsement Puppet Forge - scores License

Table of Contents

Module description

This Puppet module provide tooling for Continuous Delivery (CD) of applications in a Puppet managed environment by leveraging orchestration through Bolt or Choria.

Usage

Declaring an application

Each application is declared as an application resource. They are identified by a unique title, an application name, an environment name and a path:

application { 'acme':
  application => 'acme',
  environment => 'production',
  path        => '/opt/acme',
}

On disc, this will result in this directory hierarchy (assuming 3 deployments are created: d1, d2, d3):

/opt/acme/
|-> current@ -> /opt/acme/d3
|-> d1/
|-> d2/
`-> d3/

Your profile is likely to declare an application resource and additional resources that make it useful and point in the current directory:

class profile::acme {
  application { 'acme':
    application => 'acme',
    environment => 'production',
    path        => '/opt/acme',
  }

  file { '/usr/local/bin/acme-runner':
    ensure => link,
    target => '/opt/acme/current/bin/acme-runner',
  }

  apache::vhost { 'acme.example.com':
    docroot => '/opt/acme/current/public',
  }
}

mtree integration

Sometimes, some data must persist through deployments (e.g. uploaded files, logs). The application module install the mtree gem to manage symbolic links in the deployments directory and have them point to a persistent-data directory if a .mtree file is found at the root of a deployment.

Assuming a .mtree file is added at the root of the previous project containing:

/set type=dir uname=deploy gname=deploy mode=0755
.
    db uname=user
        production.sqlite3 type=file uname=user mode=0640
        ..
    ..
    config
        database.yml type=file gname=user mode=0640
        ..
    ..
    log
        production.log type=file gname=user mode=0660
        ..
    ..
    tmp uname=user gname=user
    ..
..

On the next deployment d4, the described hierarchy tree will be created in the persistent-data directory, and all files corresponding to leaves of this tree in the deployment will be removed and replaced by symbolic-links to the corresponding persistent-data file:

/opt/acme/
|-> current@ -> /opt/acme/d4
|-> d1/
|-> d2/
|-> d3/
|-> d4/
|   |-> db/
|   |   `-> production.sqlite3@ -> /opt/acme/persistent-data/db/production.sqlite3
|   |-> config/
|   |   `-> database.yml@ -> /opt/acme/persistent-data/config/database.yml
|   |-> log/
|   |   `-> production.log@ -> /opt/acme/persistent-data/log/production.log
|   `-> tmp@ -> /opt/acme/persistent-data/tmp/
`-> persistent-data/
    |-> db/
    |   `-> production.sqlite3
    |-> config/
    |   `-> database.yml
    |-> log/
    |   `-> production.log
    `-> tmp/

Hooks

Actions that must be performed before / after deployment and activation can be registered in hooks that can be shared by multiple applications. Before hooks can abort an operation by exiting with a non-null exit code.

As an example, one may want to use the following to deploy Ruby on Rails applications:

application::kind { 'rails':
  before_activate => @(SH),
    #!/bin/sh

    set -e

    RAILS_ENV=$ENVIRONMENT bundle exec rails db:migrate
    | SH
  after_activate  => @(SH),
    #!/bin/sh
    touch tmp/restart.txt
    | SH
}

application { 'website':
  # ...
  kind => 'rails',
}

Continuous Deployment (CD)

The goal of this module is to allow building custom CD using GitLab and Choria. The misc directory features templates to help setup a CD container. This allows you to rely on GitLab Generic Packages Repository to push the packages you build and deploy them using short lived CI/CD job tokens. The following example build and deploy a new version of an application each time a new tag is pushed:

variables:
  URL: "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/${CI_PROJECT_NAME}/${CI_COMMIT_TAG}/artifact.tar.gz"

package:
  stage: package
  only:
    - tags
  script:
    - tar zcf /tmp/artifact.tar.gz --exclude .git .
    - curl --fail --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file /tmp/artifact.tar.gz "${URL}"'

deploy:
  stage: deploy
  only:
    - tags
  needs:
    - package
  image:
    name: registry.example.com/image-builder/mco
  script: 'mco tasks run application::deploy --application=${CI_PROJECT_NAME} --environment=production --url="${URL}" --deployment_name="${CI_COMMIT_TAG}" --header="{\"JOB-TOKEN\": \"${CI_JOB_TOKEN}\"}" -C profile::${CI_PROJECT_NAME}'