Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
franck-boullier opened this issue Feb 8, 2020 · 8 comments
Assignees
Labels
complex should take 2 days to fix enhancement production This is an issue that affects the production environment. Refactoring

Comments

@franck-boullier
Copy link
Member

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?

@franck-boullier franck-boullier added enhancement Refactoring complex should take 2 days to fix production This is an issue that affects the production environment. labels Feb 8, 2020
@franck-boullier franck-boullier changed the title Docker build has to be specific to each Unee-T installation - Unecessary complexity Docker build has to be specific to each environment - Unecessary complexity Feb 8, 2020
@kaihendry
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member Author

franck-boullier commented Feb 11, 2020

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member Author

franck-boullier commented Feb 11, 2020

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
Copy link
Contributor

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
Copy link
Member Author

. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complex should take 2 days to fix enhancement production This is an issue that affects the production environment. Refactoring
Projects
None yet
Development

No branches or pull requests

2 participants