sample-application-students

This is a sample application Springboot - Vue - Postgres Student application

Backend

Simple Rest API Server

Frontend

Simple Vue.js Client

Database

Simple Postgres 9 Database

CR :

Emilio Maldonado

TP 01 :

---

I - Database

---

The -e flag creates Environment variables and overrrides those in the ENV section of a Dockerfile, in this case it is better to use this flag rather than writing the id/password in the Dockerfile. (We use --link or --network for adminer and postgre to be able to see each other).

We attach a volume to our postgre container so it can actually write its database entries on the disk so we can keep them.

Do not forget to map port 5432 (default port for postgre)

II - Backend API

---

Multi-stage build : we create one container with a firsty instance dedicated to building our app (generally heavy instance) and then we create a second instance dedicated to running (much smaller and lighter). By doing this we are allways ready to test in optimal condition or deliver a prod image to our client.

Again we need to create a network or link our containers (+ map : API -> 80 ; database -> 5432)

III - HTTP server

---

The reverse proxy is necessary so we don't access immediatly our API, this is quite usefull for differrent reasons :

1. Host many services behind the same proxy
2. Improve security (maybe have a firewall or a DDOS-counter system here)
3. Many other reasons I could not think of

IV - Docker-compose

Docker-compose simplifies Docker's usage, it allows for quick and dynamic builds while still keeping the same granurality that makes Docker usefull. It takes Docker to the "project" level by managing various instances with the same file. (personally I like to call it "a Docker script").

We put our images on an online repository so we don't lose everything when our PCs catch fire. And to allow fore easier cooperation, teamwork and even maybe to allow some of the more "technical" clients to test the latest build.

TP 02 :

---

Setup Travis CI

---

Travis CI uses .yml files (like most CI services eg : Bitbucket Pipeline, GitLab CI but not Jenkins that uses Groovy files).

mvn clean verify + npm run test = clear previous builds cache an drun test on fresh builds.

Unit test : Test the code functionnality Component test : test the project functionnality (interactions between differnt functionnalities)

testcontainers : JAVA librairies that simplifies the use of Docker containers for testing.

two stages : one for java and anotyher for node.js, for the java one Travis detects maven through the pom.xml file.

Checkpoint CI :

1. Create GitHub repo
2. Link GitHub to Travis and import repo
3. Add working .travis.yml
4. Commit and push
5. Sit back and enjoy

First steps into CD world

---

Branch develop : we don't want to build a docker image each time we push and we don't want to push all our modifications on main branch

Secured variables : for security I guess ... Those are our looging credentials.

Publish docker images, for what purpose : Everytime you push a functionnal version your colleagues will be able to pull these images to test on their machine + you always have a "latest" version of your project.

Checkpoint CD : quality gate :

1. Import repo on SonarCloud
2. Add correct lines to .travis.yml
3. Commit and push
4. Sit back and ... Go work on your sh***y code

Checkpoint CD : splitted pipeline :

When writing your .travis.yml :

A new stage for each job you want to give to Travis (or just common sense, don't restart the whole process for each new job ...)

TP 03 :

---

Setup

The /api/actuator route gives information about the "map" of our API, all the routes etc ...

Checkpoint :

Main information about our server :

"ansible_facts": {
        "ansible_distribution": "CentOS",
        "ansible_distribution_file_parsed": true,
        "ansible_distribution_file_path": "/etc/redhat-release",
        "ansible_distribution_file_variety": "RedHat",
        "ansible_distribution_major_version": "7",
        "ansible_distribution_release": "Core",
        "ansible_distribution_version": "7.9.2009"
    },
    "changed": false
}

Playbooks

basearch : You can use $basearch to reference the base architecture of the system. For example, i686 machines have a base architecture of i386 , and AMD64 and Intel 64 machines have a base architecture of x86_64

Deploy your app

docker_container : just translate from docker_compose file to the differrent roles by using the ansible documentation (has good examples, and you can easily translate from one to another).

Front

Basically we do what we did locally to test (docker etc...) but on the cloud instance and by using ansible.

Continuous deployement

Just do what you did on the last part but on Travis instead of on your local machine (run ansible on travis and the app on the server)