This project uses the scripts found in openshift-project-tools to setup and maintain OpenShift environments (both local and hosted). Refer to the OpenShift Scripts documentation for details.
These scripts are designed to be run on the command line (using Git Bash for example) in the root openshift
directory of your project's source code.
RedHat requires authentication to the image repository where the Dotnet images are stored. Follow these steps to enable this:
-
Sign on with a free developer account to https://access.redhat.com/terms-based-registry/.
-
Go to the Service Accounts section of the website, which as of October 2019 was in the top right of the web page.
-
Add a service account if one does not exist.
-
Once you have a service account, click on it and select the OpenShift Secret tab.
-
Click on "view its contents" at the Step 1: Download secret section.
-
Copy the contents of the secret
-
Import the secret into OpenShift. Note that you will likely need to edit the name of the secret to match naming conventions.
-
In a command line with an active connection to OpenShift, and the current project set to the Tools project, run the following commands:
oc secrets link default <SECRETNAME> --for=pull
oc secrets add serviceaccount/builder secrets/<SECRETNAME>
Where <SECRETNAME>
is the name you specified in step 7 when you imported the secret.
- You can now import images from the Redhat repository. For example:
oc import-image ubi8/dotnet-50 --from=registry.redhat.io/dotnet/ubi8/dotnet-50 --confirm
oc import-image rhel8/redis-6:1-21 --from=registry.redhat.io/rhel8/redis-6 --confirm
- Adjust your builds to use this imported image
At times running in a local cluster is a little different than running in the production cluster.
Differences can include:
- Resource settings.
- Available image runtimes.
- Source repositories (such as your development repo).
- Etc.
To target a different repo and branch, create a settings.local.sh
file in your project's local openshift
directory and override the GIT parameters, for example;
export GIT_URI="https://github.com/bcgov/jag-lcrb-carla-public.git"
export GIT_REF="openshift-updates"
Then run the following command from the project's local openshift
directory:
genParams.sh -l
**Git Bash Note: Ensure that you do not have a linux "oc" binary on your path if using Git Bash on a Windows PC to run the scripts. A windows "oc.exe" binary will work fine.
This will generate local settings files for all of the builds, deployments, and Jenkins pipelines.
The settings in these files will be specific to your local configuration and will be applied when you run the genBuilds.sh
or genDepls.sh
scripts with the -l
switch.
Note that you may have to comment out variables in the .param files found in jag-lcrb-carla-public-openshift\openshift.
- Install the oc cli.
- Start an OpenShift cluster. If you are using Docker you can use the
oc-cluster-up.sh
scripts from openshift-project-tools. - Run
generateLocalProjects.sh
to create the projects in your local cluster. - Run
initOSProjects.sh
to update the deployment permissions on the projects. - To fix the routes in your local deployment environments use the
updateRoutes.sh
script.
From here on out the commands used to deploy and management the application configurations are basically the same for a local cluster as they are for the Pathfinder environment.
All of the commands listed in the following sections must be run from the root openshift
directory of your project's source code.
If you are updating an existing environment you will need to be conscious of retaining access to the existing data in the given environment. User accounts, database names, and database credentials can all be affected. The processes affecting them should be reviewed and understood before proceeding.
For example, the process of deploying and managing database credentials has changed. The process has moved to using shared secretes that are mounted as environment variables, where previously they were provisioned as discrete environment variables in each component's environment. Further the new deployment process, by default, will create a random set of credentials for each deployment or update (a new set every time you run genDepls.sh
). Being that the credentials are shared, there is a single source and place that needs to be updated. You simply need to ensure the credentials are updated to the values expected by the pre-configured environment if needed.
If you are working with a new set of OpenShift projects, or you have run a oc delete all --all
to start over, run the initOSProjects.sh
script, this will repair the cluster file system services (in the Pathfinder environment), and ensure the deployment environments have the correct permissions to deploy images from the tools project.
Run;
genBuilds.sh
, and follow the instructions.
Note that the script will stop mid-way through. Ensure builds are complete in the tools project. Also, cllc-public may hang without error. This is likely due to insufficient resources in your local.
IMPORTANT: Sometimes cllc-public will fail while trying to build its image. The error will say that npm install failed. This is due to npm timing out. To fix this resources must be increased. Try increasing requested CPU to 2 cores and RAM to 2 GB.
All of the builds should start automatically as their dependencies are available, starting with builds with only docker image and source dependencies.
The process of deploying the Jenkins pipelines will automatically provision a Jenkins instance if one does not already exist. This makes it easy to start fresh; you can simply delete the existing instance along with it's associated PVC, and fresh instances will be provisioned.
Run;
genDepls.sh -e <environmentName/>
, and follow the instructions to deploy the application components to the desired environments.
When the Jenkins Pipelines were provisioned when your ran genBuilds.sh
web-hook URLs and secrets were generated automatically. To trigger the pipelines via GIT commits, register the URL(s) for the pipelines with GIT.
Copy and paste the pipeline's web-hook url into the Payload URL of the GIT web-hook (it comes complete with the secret).
Set the content type to application/json
Select Just the push event
Check Active
Click Add webhook