Internal Deployment and Management Operative

This section aims to explain how to deploy, configure and maintain software within the i3-MARKET Backplane instances.

Deployment Operative

The target audience is the i3-market project developers who are participating in the development and deployment of the i3-Market backplane

The i3-MARKET operative considers three possible deployment scenarios, categorized into manual and automatized deployments. These scenarios are the following:

  • Manual deployment scenario one or MDS1
  • Automatized deployment scenario one or ADS1, and finally,
  • Automatized deployment scenario two or ADS2

A conceptual view of I3-MARKET deployment scenarios is shown in Figure 1.

Figure 1 – i3-MARKET Deployment scenarios

Considering an I3-MARKET user role perspective, the main roles involved in the different deployment scenarios are: 

  • I3M IT Admin, 
  • I3M SW developer, and 
  • I3M third-party SW admin.

Table 6 provides the mapping between the i3-MARKET user roles and the previously listed deployment scenarios:

Deployment Scenario / User RoleI3M IT AdminI3M SW DeveloperI3M Third-party SW admin
MDS1CloseCheckmarkCheckmark
ADS1CheckmarkCloseCheckmark
ADS2CloseCheckmarkClose
Table 1 – Deployment scenarios and I3M user roles mapping

Next subsections describe in detail each identified deployment scenario.

MDS1: Manual deployment scenario one

Manual deployment scenario one (MDS1) is based on accessing the physical resources by establishing an SSH connection. Once the physical resource is accessed the user proceeds with the SW deployment manually. An overview of MDS1 is provided in Figure 2. The actors involved in these scenarios are I3M SW developer and I3M third-party SW admin.

Figure 2 – MDS1

ADS1: Automatized deployment scenario one

Automatized deployment scenario one (ADS1) is based on the provision of a set of ansible playbooks containing deployment recipes. Playbooks are one of the core features of Ansible and tell Ansible what to execute. They are like a to-do list for Ansible that contains a list of tasks. Playbooks contain the steps which the user wants to execute on a concrete physical resource, and they are run sequentially.

From operative point of view, actors involved in this scenario must cover the following deployment workflow:

  1. Create an Ansible Template (playbook) with concrete deployment instructions.
  2. Start an Ansible Job by instantiating the playbook template provided in step1.

An overview of ADS1 is provided in Figure 3. The actors involve in this scenario are I3M IT admin and I3M third-party SW admin.

Figure 3 – ADS1

Finally, Figure 4 contains a playbook example showing the main structure in terms of tags to be included I3-MARKET playbooks, which are: name, hosts, vars and tasks.

Figure 4 – Ansible playbook example

ADS2: Automatized deployment scenario two

Automatized deployment scenario two (ADS2) is based on the provision of CI/CD pipelines with Ansible and GitHub. 

An overview of ADS2 is provided in Figure 5. The only actor involve in this scenario is I3M SW developer.

Figure 5 – ADS2

The goal to reach in current deployment scenario should be aligned with I3-MARKET DevOps strategy and based on the provision of an Ansible Tower CI/CD architecture. 

Figure 6 illustrates what we should build to support CI/CD in I3-MARKET using Ansible and GitHub.

Figure 6 – CI/CD with Ansible and GitHub

As is well known, the main purpose of CI is of course to protect the master branch so that it always compiles. The only way to do it, is to check the code in another branch (like a function branch), test that code, review the code, and only merge it with the master once all tests pass. The architecture above achieves exactly that and does so with a very simplified approach that leverages Ansible Tower as our CI engine. For the CD part, only a few additional workflows would be needed to implement artifacts generated by the CI process in dev-> test-> production. Using this architecture, one could use the GitHub versions to store artifacts. GitHub has the ability to trigger a webhook when the latest version is updated, which in turn could trigger an Ansible Tower CD workflow.

Go to the beginning of the page