Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Introduction

The platform offers integration with the systems responsible for the CI/CD cycle.

For this purpose, the platform provides a tool to create and administrate the lifecycle of web applications and microservices from the control panel, following the standards of the CI/CD circle: creation, compilation, tests execution, generation of Docker images and deployment in CaaS.

The features that provides this lifecycle from the platform are:

  1. Microservice creation.

  2. Download code and development.

  3. Compilation of the code and Docker image generation from Jenkins.

  4. Deployment of the docker images in CaaS platform.

  5. Updating a Microservice.

Microservice creation

Creating a a microservice in the platform, a developer registers a new deployable artifact. Automatically the platform generates all the infrastructure to support the full lifecycle:

  • Project in GIT repository based in Maven and Spring Boot, with a predefined skeleton according to the purpose of the artifact, and including the APIs of the platform to make easier for developers the interaction with the different modules of the platform.

  • Jenkins Pipeline in charge of downloading the code from a stable branch of the GIT repository, and launching tasks of compilation, unitary and integration tests execution, quality assurance, docker images generation and publishing of images in Docker registry.

  • Deployment and execution en CaaS platform of the microservice in charge of downloading the image from a Docker registry and deploy it containerized in an enviroment where it is exposed as service and can consume services from the platform and other microservices.

Creating a new Gitlab project

If we are creating the project from scratch, we can select a template and a project will be generated in Gitlab with a code base to start work on. Each template provides a different archetype with a skeleton of code to start development, which may or may not add dependencies to the project, including those that are platform APIs such as the broker. For example, the IoT Client archetype is configured to communicate with the platform broker and perform query operations on an ontology.

In addition to the templates loaded by default, we can create our own templates by following the guide below (NEW) Templates in Microservices Platform

Creating from an existing Git project

If the code already exists in a Git repository and we just want to manage the whole lifecycle from the platform, we can indicate that we don't want to create the Git repository (uncheck the 'CREATE GIT REPOSITORY' box) and configure the existing Git repository, specifying the directory where the project resources and the Docker file are located, as well as the repository. We will need a valid token that has permissions to access the specific project.

Context and port

It is important to specify the context path defined in our application, as well as the port, so that we can later generate the correct routes in the microservices gateway. If we do not have the server.servlet.contextPath defined in our project's properties file, we need to check the "Strip context path" box.

Jenkins and CaaS container configurations

To create the microservice, you need to configure the credentials of Jenkins and the CaaS container (Rancher, Openshift, Rancher 2 or Kubernetes).

To configure Jenkins, we need to specify the URL, the user and the user token. If we want the microservice to connect to an existing pipeline in Jenkins, we will have to specify its name in Existing pipeline name, this way we will not create our own pipeline for the microservice and we will be able to use the one we have configured, whether it is our own or a generic one for the project.

For the CaaS configuration, we need to select the one we need and specify its URL, user and access token.

Once everything is configured, we can create the microservice by clicking on the Create button at the top right. If we have selected the option to create a repository in Git, this may take a few seconds.

We will be able to see and manage our microservice from the list above:

If we have created a Git project from scratch, we can access the URL and, using the developer's IDE tools, clone the repository to start working on the project and download the code generated by the platform.

Once downloaded, the project can be imported into Eclipse to start development, where you will see that the skeleton provides a number of packages and code snippets to make the work easier. Before compiling the code and generating the images, you will need to upload the changes to Git.

The user token for both GitLab and Jenkins must have the necessary permissions to create Git projects and continuous integration pipelines.

Compiling and building Docker images

At any time, we can use the auto-generated pipeline in Jenkins to compile any Git branch in the repository and generate new Docker images. This pipeline also takes care of running unit and integration tests and quality assurance rules.

Just click on the hammer ('Build service' button) and fill in the necessary fields, selecting the source branch in the Git repository you want to compile.

Once entered, click on 'Generate' and wait for the spinner to disappear, indicating that it has finished. Now it is time to deploy it.

CaaS Deployment

Once the images have been generated, we can proceed to deploy the microservice by clicking on the 'Deploy' rocket:

A pop-up window opens where we have to select from a drop-down menu the environment in the CaaS platform, the host where the CaaS will create the container and the DNS where the services will be exposed. In addition, once the environment and host have been selected, the available stacks will appear, for example to group multiple microservices within a stack.

The Docker image will be informed with the name of the image generated when doing the Build. If you have selected an existing pipeline you will probably have to go to Jenkins and get the name of the image from the console output of the build itself.

Once we click on Deploy, after a few seconds a message will appear indicating that the service has been created, and you will be able to access Rancher or Openshift to see the deployment. In addition, it will be automatically available from the outside and if it is a web application with visual components, we can navigate to the microservice by copying the URL in the link icon:

If it is a pure REST service, we can copy the generated URL and call it from any REST client, or if it has the Swagger view built in, we can access it by adding /swagger-ui/index.html to the generated URL.

Updating the deployed service

If we want to upgrade the version of the deployed microservice or overwrite an environment variable, all we have to do is click the 'Upgrade' arrow button.

A window similar to that of the deployment will open, but in this one we will be able to indicate environment variables, edit them and add new ones:

Once we have finished setting up the environment variables and the image to be displayed, click on 'Upgrade' and the process will begin, which will take a few seconds.

  • No labels