Docker build has to be specific to each environment - Unecessary complexity

[franck-boullier]

Context:

For the Unee-T frontend to work, we can describe the things we need as such:

• A: Docker image that has everything we need to run the MEFE code C.
• B: Infrastructure that we need to run the MEFE code C on the Docker image A.
• C: MEFE Code so that user can create and manage cases.

In order to deploy some of the Unee-T components (frontend but also bugzilla-customization) We need to:

• Step 1: Define the Docker image A that is able to run the MEFE code
• Step 2: Test the existing MEFE code C on that new image A to make sure that the existing MEFE code C still works as intended.
• Step 3: Build the valid image A on the chosen AWS infrastructure B.
• Step 4: Deploy the MEFE code C on the chosen AWS infrastructure.

Other things to Keep in mind:

• Unee-T can be, and is, deployed in several different installations (Unee-T, Unee-T INS, etc...)
• ALL installations and all environments in each installation (DEV, PROD, DEMO) should share the same Docker Image A.
  That same share Docker image A should then be used and deployed on each Infrastructure B-DEV, B- DEMO, B-PROD for each installation (Unee-T, Unee-T INS, etc...).
• Some installation WILL make changes in the MEFE code C (turn off some functionalities, edit some of the UI, etc...). Most of these change will NOT require a change of the Docker image A or changes in the infrastructure B that they use to run the application.
• Changes in the Docker image A are happening much slower than changes in the MEFE code C.
• Changes in the MEFE code C are happening frequently.

The problem:

In the current version of the master, we have fused the creation and test of the Docker image A with the creation and test of the MEFE code C.

Some of the consequences of the problem:

Each installation/Environment has its own custom Docker Image A:

This is not necessary: each Unee-T installation (Unee-T, Unee-T INS, etc...) should share the same docker image frontend-docker-image as they are sharing some of the other Unee-T libraries (ex: unee-t/env)

We do many unnecessary steps each time we change the MEFE Code C:

Today, each time we do a minor change in the MEFE code C we are:

• Step 1: Re-creating a brand new Docker image A
• Step 2: Re-deploying that Docker image A on our infrastructure B
• Step 3: Updating the MEFE code C

In the vast majority of the cases, we do NOT need to do Step 1 and 2.

It should be possible to

• Changes the MEFE code C to add/remove functionalities or do minor cosmetic changes
• Still use the same Docker image A.
• Update the code that is running on Infrastructure B instead of rebuilding everything.

Maintenance of the Docker image is problematic:

Because each environment (DEV, PROD, DEMO) in each installation is building its own Docker image A, it is complex to centrally:

• Do some upgrades in the components and dependencies in docker image A (Maintain the Docker image).
• Test these changes and make sure the current version of the MEFE code C still works as intended.

Possible solution:

We can/should create a specific repo frontend-docker-image dedicated to maintaining the Docker Image A.
We can then use that repo frontend-docker-image as a single central component that can be shared by all the forks of the MEFE Code C (Unee-T, Unee-T INS, etc...).

@kaihendry do you have a better solution that will solve all the issues that have been listed here?

[kaihendry]

Sorry, I don't quite understand. Why does it have to be "has to be specific to each environment" exactly?

https://hub.docker.com/repository/docker/uneet/frontend will work across {dev,demo,prod}.

[franck-boullier]

https://hub.docker.com/repository/docker/uneet/frontend will work across {dev,demo,prod}.

but is will not work on a different INSTALLATION of Unee-T (Unee-T INS, other future Unee-T installation) <--- that is a problem

[franck-boullier]

Also with how the code is built currently, if someone forks the Unee-T frontend codebase and tries to do some changes to the code, then these changes will trigger a new build of the docker image.

One issue is that this build in the forked repo will automatically fail (as is should) because it's trying to update the Docker image to the Unee-T Dockerhub account and has no credential for this account.

Example: an update to the forked code Unee-T INS will try to build a new image in the Unee-T main code <-- this is wrong

[kaihendry]

I don't understand why uneet/frontend will not work in another different installation.

Because you intend to fork the code? Or what is the reasoning?

[franck-boullier]

I don't understand why uneet/frontend will not work in another different installation.

One of the reason is explained here #895 (comment)

[franck-boullier]

Because you intend to fork the code?

yes the code has to be built so it can be easily forked (see the Unee-T INS example as a case in point)

[kaihendry]

So when you fork the repo you will need to ensure the Docker repo variable is updated.

Don’t quite understand this “unneccessary complexity” in the bug title. It’s a reality if you fork the code.

[franck-boullier]

. It’s a reality if you fork the code.

It does not have to be a reality if we create a dedicated repo for the Image we need.
Read the description of the issue again if you have issues understanding the concepts I'm trying to highlight.

For the Unee-T frontend to work, we can describe the things we need as such:

• A: Docker image that has everything we need to run the MEFE code C.
• B: Infrastructure that we need to run the MEFE code C on the Docker image
• C: MEFE Code so that user can create and manage cases.

In order to deploy some of the Unee-T components (frontend but also bugzilla-customization) We need to:

• Step 1: Define the Docker image A that is able to run the MEFE code
• Step 2: Test the existing MEFE code C on that new image A to make sure that the existing MEFE code C still works as intended.
• Step 3: Build the valid image A on the chosen AWS infrastructure B.
• Step 4: Deploy the MEFE code C on the chosen AWS infrastructure.

The problem:

In the current version of the master, we have fused the creation and test of the Docker image A with the creation and test of the MEFE code C.