DEV Community: Hamida

Docker Part 1 : A brief theoretical overview

Hamida — Sun, 16 Feb 2020 09:16:55 +0000

Although I am using Docker for a while now, the theory always seemed a bit complex to me, so I decided to do the in depth search to understand the theory and put it for me and others in simpler words. Although it wouldn't be as simple as this one line from the Stack Overflow user 'L0j1k' that kinda sums it all up :

Docker is just a fancy way to run a process.

But first Virtualisation

Virtualisation in a broad sense means creating a simulated, virtual computing environment.
There are four virtualisation categories:

Desktop virtualisation: where a centralised machine manage individualized desktops,
Network virtualisation: where a network bandwidth is split into independent channels to be assigned to different device,
Storage virtualisation: where a hardware storage information is abstracted to create a logical view of storage to be consumed by devices,
Software virtualisation: where in a hosting physical environment, we get to create several isolated virtual environments.

What about Docker ?

Docker is not under any of the above categories. It's a container-based virtualisation (OS-level one ).
All the containers on the host machine share the same kernel and run on the same OS as the host. Each container is identified by a namespace so the kernel can insure the execution isolation.

So containers ?

A container ideally runs a single process, it's stateless also so it can be created and destroyed without affecting the application behavior.
Since an application usually use multiple containers, Docker offers a YAML configuration file, that allow us to build the different containers and put them on the same virtual network.

What's an Image then ?

Easily put, a Docker Image is a read-only template of instructions to create a docker container.
It's the equivalent of an Immutable VM snapshot.
It's the snapshot of the docker container at a specific point of time that contains all the elements needed to run an application (code, configuration files, librairies,etc.)

See you soon in the practical part about Docker (a link would be added later when the other part is up).

Using RabbitMQ in a Symfony 3.4 project -- Part1: Producer --

Hamida — Sun, 25 Aug 2019 19:26:21 +0000

When I had to use RabbitMQ in a symfony project, I had a hard time with the choice of bundle or Component to use, so in this example I am creating a fully fonctionnal example using Enqueue and symfony 3.4.
As per the Enqueue choice, I find it (enqueue.forma-pro.com) the best documented solution for php projects coupled with a wide range of transports to message brokers (amqp, redis, kafka,...).

This example will allow us to make connect to different endpoints available for r/SpaceX API on a random way. All the code examples and configurations are strictly usefull with the 0.9.12 version of the enqueue-bundle.
The full code can be found on https://github.com/Haamida/RestRabbit.

1. Configuration

The first setp would be to run

composer require enqueue/enqueue-bundle enqueue/amqp-lib

enqueue/amqp-lib here is my library of choice to connect to RabbitMQ. I should mention here that amqp-lib depends on the bcmath extension so you have to make sure that its installed or enbaled.

Now that the bundle is added to the project (composer.json and AppKernel.php), let's procede with a minimalistic config in enqueue.yml :

enqueue:
  default:
    transport: 'amqp+lib:'
    client: ~

Now the connection parameters in parameters.yml

    queue_rb: spacex_q
    topic_rb: spacex_t
    host_rb: 127.0.0.1
    port_rb: 5672
    user_rb: guest
    pass_rb: guest
    vhost_rb: /

Here for simplicity,I kept the default port, user,vhost,...( Sure that should be changed for production).
It would be usefull to have the Rabbit Management plugin enbaled to monitor the interactions with the queue :
rabbitmq-plugins enable rabbitmq_management
Now head for http://localhost:15672/ to get an overview of the queues and messages.

2. Connection, Topic and Queue

To send our produced messages to the queue, we need to set up our connection.
First step would be to get an instance of the connection Factory :

$factory = new AmqpConnectionFactory([
            'host' => $this->getParameter('host_rb'),
            'port' => $this->getParameter('port_rb'),
            'vhost' => $this->getParameter('vhost_rb'),
            'user' => $this->getParameter('user_rb'),
            'pass' => $this->getParameter('pass_rb'),
            'persisted' => true,
        ]);

That would allow us now to create a connection context a topic and a queue (if they are not already created)

 $context = $factory->createContext();
 $topic = $context->createTopic($topicName);
 $topic->setType(AmqpTopic::TYPE_DIRECT);
 $context->declareTopic($topic);
 $queue=$this->createOrUseQueue($context,$queueName);
 $context->bind(new AmqpBind($topic, $queue));

In the above code, I created direct exchange type of topic so that the message will be routed directly to the queue with the matching routing key. That's because per rabbitmq message flow, a message is delivered first to an exchange than depending on the exchange type:

Direct: sent directly to the corresponding (by routing key)queue
Fanout: sent to all the queues bound to the exchange
Headers: sent based on the message headers
Topic: sent to one or more queues based on a correspondance between the routing key and the routing pattern These are the principle Exchange types, a more in depth explanation can be found here Exchanges-routing-keys-bindings. After configuring the topic, we proceed to create the queue that we later would bind to it.

 public function createOrUseQueue($context,$queueName){
        $queue = $context->createQueue($queueName);
        $queue->addFlag(AmqpQueue::FLAG_DURABLE);
        $context->declareQueue($queue);
        return $queue;
    }

Practically, it's the same logic for creating a topic. I added the flag FLAG_DURABLE so the queue could survive the broker restart/technical problems. That being said, a durable queue doesn't guarantee that the messages would survive too, they should be labeled persistant to have that effect.

Send Message to queue

Now that everything is set, we can produce and send messages:

 switch (rand(1, 3)) {
                case 1:
                    $message = $context->createMessage('roadster');
                    break;
                case 2:
                    $message = $context->createMessage('rockets');
                    break;
                case 3:
                    $message = $context->createMessage('missions');
                    break;
                default:
                    $message = $context->createMessage('info');
            }
$context->createProducer()->send($this->createOrUseQueue($context, $this->getParameter('queue_rb')), $message);

This is all for the producing part, in the next part we will configure our messages to be persistent and create our Consumer that will allow us to get information from the SpaceX API.

Fixing React build failure

Hamida — Sun, 05 May 2019 15:33:02 +0000

I was so enthusiastic about deplying my first react project, a very beginner version.
All that faded away after having to go over and over on 'npm install' and 'npm build' and failing miserably to build my simple one page project.
Hours of search and nothing useful or helpful.

Turns out, the extra Babel dependencies I added to the project following some tutorials created some sort of a confilct that caused the react-scripts to fail everytime I attempted the build command.
This can be traced in this https://github.com/facebook/create-react-app/issues/5135 issue report.
Now finally, I got to deploy my too naive try after changing the whole app idea and keeping the same weird name (Sneaky-React). (https://nifty-hypatia-73966f.netlify.com/)

Is RabbitMQ a fit solution for request timeout problem ?

Hamida — Wed, 01 May 2019 16:00:02 +0000

The system am working on relies on the response received from an external API, frequently now, the requests we are sending finish with a timeout and we end up losing the transaction in progress.

We need our requests to be resent over and over until the API responds so we could continue the transaction.

I got advised to use RabbitMQ so that it queues the requests until the API responds, so this way my application should be a producer that pushes to the queue, what I still can't undrestand is how I am going to receive a callback from the queue once my message (request is excuted sucessfully) ?
Does RabbitMQ guarantee that my request reached its destination sucessfully? will it keep trying to send the request until the api responds (the api is available for exchanges) ?
How will my application resume the execution related to the request ? my intial idea now is to isolate that code that relies on the immediate response of the external API.

Is it even RabbitMQ the best choice here ?

I have zero experience with RabbitMQ that's why I am still skeptical if it's appropriate in this use case so am sorry in advance if some of these questions are completly dumb.

PS: we are keeping track of the timeout data.
The API we are connecting to is part of an external system, we have no control
over it.

what's The next step for a static React js app ?

Hamida — Wed, 01 May 2019 09:07:14 +0000

With no background in React and the so little information I have, I managed to push a static one page website.
It's a slightly "Hello World" look alike, yet I just wanted to put it up to force myself to commit. I have a terrible case of overengineering and shiny new stuff syndroms, so please be nice in judging the code 😊😊 .
This is the repo: https://github.com/Haamida/Sneaky-React

Coming from a Symfony and php background where the front and back are tightly close, I figured that the next step for this front is to link it to a backend where we receive the reservation and newsletter inscriptions. I still have no idea how to it and still doing the research, any insights are appreciated.