[FOLIO-2131] SPIKE: how to deploy containers based on feature branches Created: 01/Jul/19  Updated: 03/Jun/20  Resolved: 07/Aug/19

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Jakub Skoczen Assignee: John Malconian
Resolution: Done Votes: 0
Labels: platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks UXPROD-1827 CI-integrated continuous deployment (... Closed
Relates
relates to UXPROD-2066 CI architecture and process to allow ... Closed
relates to FOLIO-2055 create an Ansible role for backend-mo... Closed
Sprint: CP: sprint 69
Story Points: 5
Development Team: Core: Platform

 Description   

Wayne Schneider John Malconian mark.stacy Ian Hardy let's provide steps here and consider how/where to upload descriptors for feature builds.



 Comments   
Comment by Wayne Schneider [ 01/Jul/19 ]

One possible approach for each PR that includes a backend dependency based on a feature branch (leaving out how to figure that out for now):

  1. Build feature branch and deploy container. Service name should be the same as the module ID (build and deploy from CI, without first posting image to Docker Hub?)
  2. Stand up an Okapi instance (needn't necessarily be a cluster)
  3. Pull module descriptors from upstream repository
  4. Post module descriptor from feature branch (note that module ID must be unique to this Okapi instance)
  5. Post deployment descriptor to Okapi /_/discovery/modules API
  6. Create tenant
  7. Post install.json for tenant that includes the module ID of the module under development

What is the scope of this issue? Is this only for feature branches of backend modules? That is, can a front-end module feature branch request one (or more) feature branches of backend modules?

Comment by Jakub Skoczen [ 02/Jul/19 ]

Wayne Schneider I think we could make creating tenants and installing the module optional in this pipeline and rely on the front-end pipeline to do this.

Comment by Jakub Skoczen [ 02/Jul/19 ]

Wayne Schneider John Malconian Adam Dickmeiss Since there could be potentially MANY feature branches at any given point it would be good if the CI deployment were opt-in through a setting in a configuration file (Jenkinsfile?) and off by default. E.g something like:

ciDeploy = "never" | "pr" | "commit"

pr would deploy the branch when a PR is issued from the branch, commit would (re)deploy on any commit to the branch.

we may also consider adding:

ciDeployPRTarget= name-of-the-target-pr-branch

to constrain deployment only to PRs issued against a specific branch, defaulting to master probably makes sense.

Comment by Wayne Schneider [ 08/Jul/19 ]

One issue with multiple Okapis using the same set of running modules is that unless we can guarantee that the tenant ID is unique, we will run into storage conflicts.

Comment by John Malconian [ 25/Jul/19 ]

'ciDeployPRTarget= name-of-the-target-pr-branch' is a good idea. I'm not sure about 'ciDeploy'. We need to be clear that only PRs issued against a particular branch will create a preview environment and deploy a container for that branch. This will not work with any other branch build. We need the PR for various reasons. There is no need to do anything special for additional commits against the branch that has an open PR. Any new commits to this branch will redeploy a new container into the same preview environment. Not sure of the mechanics of this yet, but that's how it should work.

Here's how I envision this on the kubernetes side: When a PR is created, a new namespace is created in the cluster. A docker image is built and container deployed to the namespace in the cluster as part of the build pipeline. We'll probably want a local docker repo in the cluster and not use Docker Hub for these images. For the PR preview, we can either deploy a local okapi instance to the PR namespace or use an okapi running in the primary folio namespace. Either way, we'll need to create virtual service definitions that allow us to access services in other namespaces using the 'ExternalName' service type which is essentially a local namespace alias to a service that resides in a different namespace. If we use a local okapi instance, then we would need to create a service definition for each module that resides in the primary folio namespace so that the local namespace okapi can access each module running outside the PR preview namespace. The service alias would be used by Okapi's discovery.

Advantages to using a local namespace okapi:

  • Any temporary module descriptors that are posted to Okapi, PR-based tenants, and so forth will be destroyed when the namespace is destroyed.

Disadvantages:

  • We may need to provision a dedicated DB in the PR preview namespace?
  • We need to create service aliases in the preview namespace for each module we are enabling.

On the other hand, we could create a service alias in the preview namespace that points to a dedicated okapi instance in the primary folio namespace instead.

The advantages of this approach would be:

  • Fewer service alias definitions would need to be created. We would only need two total - one in the preview namespace for okapi and one for the branch module that would need to be added to the primary folio namespace so that the folio namespace okapi can access the branch module in the preview namespace. We would need to remove this service definition from the folio namespace as part of the cleanup process.
  • One DB

Disadvantages:

  • We'd need to clean up each tenant when the PR is closed as well as the module descriptor(s) that are posted to okapi.
  • Mixing PR module descriptors may cause unpredictable results when Okapi is doing dependency resolution for other tenants.

When the PR is closed the namespace all associated services associated with that namespace are destroyed.

Generated at Thu Feb 08 23:18:26 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.