Table of Contents
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.
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 Role | I3M IT Admin | I3M SW Developer | I3M Third-party SW admin |
MDS1 | |||
ADS1 | |||
ADS2 |
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.
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:
- Create an Ansible Template (playbook) with concrete deployment instructions.
- 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.
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.
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.
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.
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.
Free* Open Source Software Tools for SMEs, Developers and Large Industries Building/Enhancing their Data Marketplaces.
For more detail and source code please refer below link.