SWPC - Swimming pool controller

The project consists of monitoring the metrics of a swimming pool in real time using golang. The metrics are collected through sensors inside the pool connected to an esp32 board.

The board, depending on the parameters configured in the application via web, sends the metrics information to a server, which broadcasts the metrics to all the connected subscribers.

The metrics obtained by the user are: Temperature, ORP (Oxidation Reduction Potential) and PH. Other metrics such as chlorine and water quality are calculated by two predictive models (artificial intelligence), namely a regression model and a decision tree model.

The metrics can be visualised anytime and anywhere via a web application.

The system is prepared for both microcontroller and server crashes. Therefore, when one of the parts detects that the other is available, the system starts to work normally.

Special care has been taken regarding memory and cpu consumption. Specifically, measurements have been made and for 70 clients connected in real time, values of 20 MB of memory and 0.5% of cpu have been obtained. The system is ready to deploy in aws beanstalk immediately.

Code and documentation

The power of Spring Cloud Pipeline and Spring Cloud Contract to deploy microservices on kubernetes

In this video we will try to describe how to deploy microservice architectures on kuberentes combining Spring Cloud Pipeline and Srping Cloud Contract. We will see how we can save time and money building our pipeline with Spring Cloud Pipeline and our tests using Spring Cloud Contract.




References in the video:

https://github.com/CloudPipelines/
https://spring.io/projects/spring-cloud-contract
https://github.com/davsuapas/DanceSchool
https://github.com/davsuapas/DanceSchool-CloudPipeline

Spring cloud netflix + Kubernetes + Docker. Part II

Spring cloud netflix + Kubernetes + Docker

New article to deploy microservice on Kubernetes 

Execution

1º) We download rabbitmq image using the next command:

docker pull rabbitmq:3-management

2º) We download the code:

git clone https://github.com/davsuapas/KubernetesMicroservices.git

3º) We build the docker images of our services from project:

gradle clean build distDocker

4º) Checking that the docker images has been created:

docker images

5º) Launching the kubernetes cluster (from folder where we download kubernete repository), executing the next command into a new terminal:

sudo hack/local-up-cluster.sh

6º) We create all pods executing the next command from kubernete-config (into project repository) folder.

./createpods.sh

7º) Checking that all pods and kubernete service have been created correctly:

kubectl get pods, services

 

We can see that all have been created with running state. We can also see that both order and order line have a random name. This is because these pods can have multiple instances.

8º) Checking that the discovery service is working. So, we must find out the IP address assigned by kubernetes. We do this, running the command:

kubectl get -o json pod discovery

Once we get the result we seek the "podIP" word and get the address that we will use in the broswer.

We write in the browse http://172.17.0.3:8761/ and checking the services:

9º) We call order service using curl:

curl -s 172.17.0.4:8765/orders/orders/1 | jq .

We get the address of the previous figure in the eureka viewer. We look for the address assigned to edge. Edge will be the dispatcher to our order service.

 

10º) We simulate a shutdown OrderLine service, and we will see while the instance is shudown, the order service is still working correctly. It is possible, because hystrix manage the states of services and if there is error it will redirect the call to a method to work. In our case "defaultOrder" method.

 

Before we can see the state of services into monitor, we must get the address so monitor service as turbine service. We use the same way to get address, that we saw in the 8º) point.

kubectl get -o json pod monitor

kubectl get -o json pod turbine

We write in browse http://172.17.0.7:7979/ and the page we write http://172.17.0.5:8989/turbine.stream and click "monitor stream" button.

172.17.0.7 :  monitor address

172.17.0.5 :  turbine address

We can see that the circuit for order service is closed. This means that the circuit supports requests.

Now we going to drop orderline pod using the next command:

kubectl delete pod orderline-47fhv

orderline-47fhv: Depend of the name gaven by kubernetes.




The pods is dropped and automatically the system restart a new pod.

In the figure below we can see how the channel is open. This means you can not connect to OrderDetail and redirects the call to a failure method, which in our case return a order by default.



Order service work correctly, even if the circuit is open

Finally when the OrderLine service has been raised, the channel is again closed, and the service work fine.