FT_SERVICES

This is a school project for the 42cursus.

note: Each subparts of this project has its own readme.md, they all contain the informations used to build from the Dockerfile and also contain tips and a bunch of details about implementations and good practice

note2: If you are a 42 student, i made a separate README_FOR_42PEERS.md it contains some helpful hints on how to approch the subject. I also made a correction script: correct_peer.sh

I) OVERVIEW OF PROJECT

The projects is about deploying automatically a cluster of microservices using homemade container images and an orchestration tool. The orchestration tool for managing the containers and their interconnections is kubernetes, it creates and maintains the cluster state for us. Each container image is build from scratch from the alpine linux base image for lightweight and learning purpose. The whole service we are going to run is made of the following microservices (each in its dedicated container).

Nginx server
FTPs server
Wordpress
PhpMyAdmin (for managing the wordpress database)
MySQL database (database for the wordpress site)
Grafana (visualisation for monitoring the containers)
INfluxDB database (database for the grafana)

From the outside world, the access to the cluster is made through a load balancer. MetalLB is used for this purpose. It will publish only one IP to access the whole cluster.

II) USAGE

PREREQUISITES:

-docker installed and running. -minikube installed, and its dependencies. Especially kubelet. -be on Linux

SETUP.SH

In the root folder you should be able to execute the script setup.sh.

./setup.sh

setup.sh will start minikube according to the OS, it will then build our own custom docker images. Then it will creat all the kubernetes necessary objects. The interconnection between those object is set within the configuration files (yaml format).

CREDENTIALS

for the entire project, the credentials are:

user="user"
password="password"

note:Those are defined as environement variables in each dockerfile with a default value. At runtime they are overidden through the use of new environment variables passed in our yaml configuration files. The redefinitions of those variables are found either in the configmaps(non sensitive) and secrets(sensitive).

important note: secrets.yaml file should be stored independently.

III) MINIKUBE AND METALLB:

MINIKUBE:

It is a tool allowing us to deploy a very basic version of a cluster, but locally on our machine, for development purpose. The cluster is made of only one node which includes the master process as well. Normally a real kubernetes cluster would require at least one master node, and a worker node (on which our kubernetes objects for our app are deployed).

DRIVER USED

This project was developped on a ubuntu VM (Ubuntu 18.04.5 LTS) on which docke was installed and running. Therefor the possibility to use directly the docker engine instead of a Virtual Machine to deploy our minikube cluster was used.

minikube start --vm-driver=docker

VERSION USED:

minikube version: v1.9.0 note: this previous version does not come withe the metallb addon.

METALLB:

Metallb allows us to provide an external Ip address to our kubernetes services objects of type LoadBalancer on bare metal server. So no need to go through a cloud provider. Metallb will need to provide ip addresses in our case that are in the same subnet as the docker0 bridge (the bridge the docker engine creates). This because we start our cluster within the docker engine.

IV) MORE ABOUT KUBERNETES OBJECTS(K8S):

Oour cluster will be composed of different kubernetes objects:

deployments theiy are a superset of pods, so that we dont have to handel them individually.
pods, they are basically running a container (abstraction over containers).
services (either reachable from the exterior (type: LoadBalancer) or not (type: ClusterIp) they will allow us to make our pods communicate with each others within the cluster for example.
volumes, making it possible to maintain data persistence even when containers crash and are being restarted.

V) UNDERSTANDING PROJECT PARTS:

1. "NGINX" CONTAINER:

It is a container running an Nginx server(port 443 or port 80 redirecting 443), as well as an ssh server(port 443) It will also:

act as a reverse proxy server to the container phpmyadmin with the /phpmyadmin in the URI,
give a temporary redirect of type 307 to the container running wordpress.

More details on the dedicated README.md of this microservice: see srcs/nginx/README.md.

2. "FTPS" CONTAINER:

We will use the vsftpd ftp server because it is the most lightweight (important for containerised apps) and trusted. The logs are made accessible to docker. The anonymous connexions have been disabled, the ssl/tls connexion is used, and the connexion is chrooted for learning purpose.

More details on the dedicated README.md of this microservice: see srcs/ftps/README.md.

3. "WORDPRESS" CONTAINER:

Tthis container will listen on port 5050. it can also be reached through the nginx container that makes a temporary 307 redirect to it.

The wordpress is already set up with a couple of users etc (the famous 5 minutes install is done). Two methods were possible:

either precreate a database and import a dump in the mysql container (very rigid because we cannot change the site name etc).
use the wp-cli tool from within the wordpress container at startup, much cleaner solution. dynamically configurable when starting the cluster.

Since the folder wp-content stores the media(not uploaded into the database), a persistent volume should be mounted there.

More details on the dedicated README.md of this microservice: see srcs/wordpress/README.md.

4. "PHPMYADMIN" CONTAINER:

It connects to the mysql database container. It can be accessed on port 5000, or through the nginx contaier (ports 80 et 443) with the uri /phpmyadmin

More details on the dedicated README.md of this microservice: see srcs/phpmyadmin/README.md.

5. "MYSQL" CONTAINER:

This is a statefulset application, therefore it require to mount a persistent volume otherwise the data will be lost between different containers lifecycle.

More details on the dedicated README.md of this microservice: see srcs/mysql/README.md.

6. "TELEGRAF" CONTAINER:

This is a open choice in the subject, it is collecting metrics and feeds them into our influxdb database. Telegraf is a plugin-driven agent that collects time series data. there is a pluggin for kubernetes.

6. "INFLUXDB" CONTAINER:

It will receive time series data in a database, and grafana will access that database to display some nice visuals.

7. "GRAFANA" CONTAINER:

Create your own dashboards to display the time series data you collected on whatever. in our case the data we collected on pods.

charMstr / ft_services