Home › Cloud › Private cloud › Onboard your team

Onboard your team to private cloud hosting

Ready to start building your application in the B.C. government Private Cloud? Learn how to onboard your team onto the platform.

Before you start

Before you start the onboarding process for the B.C. Government Private Cloud Platform as a Service (PaaS), make sure you and your team have the recommended knowledge and skills to use the platform.

B.C. government ministries have specific requirements for their product teams when onboarding onto the platform. Before reaching out to us, engage with your Ministry Information Security Officer (MISO) to learn more.

Product teams from the following entities must engage with Attorney General’s Information Security Branch (ISB) directly at AG Security prior to submitting a request for a new product:

  • Ministry of Attorney General
  • Ministry of Public Safety and Solicitor General
  • Ministry of Emergency Management and Climate Readiness
  • BC Housing Crown Corporation

Step 1: Attend an onboarding meeting

If your team is interested in joining the B.C. Government Private Cloud PaaS, the first step is to request an onboarding meeting with the platform Product Director. During the meeting, you’ll get an overview of the B.C. Government Private Cloud PaaS and what we do to support the platform. You’ll also learn what your responsibilities will be as a product team working on the platform.

The meeting will also cover:

  • A high-level discussion of the technical architecture of your planned application
  • An overview of how to get set up on the platform and the resources that your product will be allocated
  • Where to get help or support while working on the platform
  • Our communication channels
  • What it means to be a part of the platform community

The onboarding meeting is also your opportunity to ask questions and learn more about RedHat OpenShift, the technology behind the platform that product teams use to build and deploy cloud-native applications.

Preparing for your onboarding meeting

To get the most out of your onboarding meeting, we recommend preparing for it by reading about the platform. 

Step 2: Review Memorandum of Understanding (MoU)

This Memorandum of Understanding (MoU) below outlines the expectations for product teams and the Platform Services team around the support, maintenance and cost of using the B.C. Government Private Cloud PaaS to host applications.

Effective date

This agreement is in effect once you provision a project set on the B.C. Government Private Cloud PaaS OpenShift platform. It remains in effect for the entire time your application is hosted on the platform and only ends once your application is removed from the platform. 

For applications already on the platform, this MoU is immediately applicable.

Before reading the MoU

Understand the service we provide with the B.C. Government Private Cloud PaaS.  

Product team responsibilities

As a product team, you are responsible for your applications, including their build, configuration, launch, maintenance and retirement.

It’s your responsibility to:

Your team is solely responsible for building, deploying and monitoring of your application on the B.C. Government Private Cloud PaaS. We don’t provide support for these activities.

If you need assistance or support while using the B.C. Government Private Cloud PaaS, you have several support options on the platform.

Your applications on the B.C. Government Private Cloud PaaS are also expected to adhere to B.C. government standards for privacy and personal information.

Platform team responsibilities

As the Platform Services team, we are responsible for the B.C. Government Private Cloud PaaS and its tools, including operational support, monitoring, troubleshooting and access management.

It’s our responsibility to:

  • Review and provision a new project request on the Platform Product Registry that will provision you with namespaces on the platform and provide access to the product owner and two technical leads
  • Develop automation for user access management for the OpenShift platform and the platform tools
  • Prepare and maintain STRA/PIA for the platform and supporting tools
  • Maintain platform security (network, access control for cluster-wide-roles)
  • Conduct annual security penetration testing of the platform to identify exploitable vulnerabilities and remediate them
  • Prepare and maintain Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) for the platform and supporting tools
  • Management of B.C. government’s data center in Kamloops and Calgary by on-prem Platform Operations team
  • Configure the OpenShift clusters on the platform for resiliency and availability
  • Monitor up-time, performance and resource usage across the platform
  • Maintain the platform’s physical infrastructure and OpenShift software, including patching and upgrades
  • Build and maintaining the platform service and tools and make them available for product teams to use in their applications

To support you and the platform community, we also:

The B.C. Government Private Cloud PaaS is supported by 2 platform teams: the Platform Services team and the Platform Operations team.

Hours of service

Our regular business hours are weekdays from 9:00 am to 5:00 pm Pacific Time, excluding statutory holidays. We address non-critical platform issues and maintenance during these hours. 

After hours support is provided by the Platform Operations team and is only available for platform outages and other incidents that impact the service. We do not provide after-hours support for applications. 

Uptime

The B.C. Government Private Cloud PaaS is available to use 24/7, except during planned outages within the Kamloops and Calgary data centres. Planned outages are communicated through Technical Information Bulletins (TIBs).

Review our platform availability commitments or check the current and historical uptime of the platform.

To subscribe to receive TIBs by email, send a request. To ensure you don’t miss any important TIB updates, we recommend setting up an Outlook filter to watch for emails with subject lines that include the text “Managed Container Service”. 

Project provisioning lead times

You’ll receive access to a new project within 24 hours of submitting a project provisioning request. 

This timeline may get extended if you have not completed all onboarding requirements at the time of submission.

Support incident response times

For support incidents, we have a standard response flow and times.

Change windows for the platform

Most maintenance activities are done during regular business hours. They’re typically non-disruptive to applications hosted in OpenShift that are configured for resiliency and high-availability. 

You are responsible for monitoring your applications at all times. You must ensure that your applications are resilient and can undergo maintenance without any disruption to service. 

Change communications

Our changes follow the OCIO change management process. When a change occurs on the platform, we’ll provide notification in advance in these ways: 

  • Minor changes are announced 24 hours in advance in the Rocket.Chat #devops-alerts channel. An example of a minor change is an upgrade to the OpenShift Container Platform (OCP) patch number, small bug fixes or other low-impact changes
  • Emergency changes are announced as soon as possible in advance in the Rocket.Chat #devops-alerts channel. An emergency change is performed to recover a failed service, prevent a failure or address a security vulnerability
  • Medium changes are announced five business days in advance in the Rocket.Chat #devops-alerts channel. An example of a medium change is an upgrade to the OCP minor version number, with limited impacts
  • Major changes are announced 10 business days in advance in the Rocket.Chat #devops-alerts channel and through the platform newsletter. High impact changes are also announced in a Technical Information Bulletin (TIB). An example of a major change is an upgrade to the OCP major version number with a potentially backward in-compatible change

Ways to receive communications

To receive information about platform changes and updates, you can: 

Custom requirements

If the base service or existing service options within the B.C. Government Private Cloud PaaS don’t meet your organization’s business needs, custom services can be negotiated. Email us at PlatformServicesTeam@gov.bc.ca to discuss your requirements.

Step 3: Set up your access to OpenShift

There are 2 types of accounts supported on the B.C. Government Private Cloud PaaS for accessing OpenShift and all other products: IDIR and GitHub ID.

You need to have at least one of these 2 accounts before you can work on the platform or participate in the platform community. Every member of your product team should have their own account(s).

IDIR

IDIR is an official identity issued by the B.C. government to its employees and contracted resources. You receive your IDIR when you begin working with the B.C. government.

GitHub

GitHub is a leading hosting platform for building, deploying and maintaining open-source projects. It provides tools for project management, collaborative development, issue tracking, team administration, automation and more. You’ll use GitHub to store and manage your code and collaborate with the open-source community. 

In order to contribute to GitHub repositories in bcgov organization owned by B.C. government, including your own project repository, you must have a GitHub account with two-factor authentication enabled and added as a member to the bcgov organization in GitHub.

You can create a GitHub account at any time. Accounts can be added to the bcgov organization in GitHub by an existing bcgov organization member using the Just Ask! tool.

Learn more about different organizations owned by the B.C. government in GitHub.

GitHub and open-source projects

Our Digital Principles encourage us to work in the open. GitHub is the leading platform for open-source projects and allows the Province to collaborate with the open-source community. Using GitHub, we can build software, support innovation and save time and money.

As a product team on the B.C. Government Private Cloud PaaS, you’ll use GitHub to build your application. On GitHub you can host your code, work with your team and collaborate with other product teams and the broader open-source community. 

GitHub gives you the unique opportunity to build your application in an open and transparent environment. Open-source coding facilitates the use and improvement of shared code and components. It also lets teams support one another to efficiently develop and deliver digital services across teams, departments and ministries.

Learn more about building your application in open source.

Open and transparent development

Open-source development also involves building your application to follow open-source development best practices. Make sure your work is clear and well documented.

As you build and improve your application, keep it well organized and labeled. Thorough documentation in your application helps other teams benefit from your work. It can also help other developers understand your code if they’re trying to help you resolve an issue with your application. 

Other teams are also maintaining their application to follow best practices and you’ll be able to benefit from their well-documented work as well.

Make sure you understand the requirements associated with licensing intellectual property in GitHub.

Organizations in GitHub owned by B.C. government

There are different organizations that B.C. government owns in GitHub. Find an organization that is right for your code.

Learn about the different B.C. government GitHub organizations.

Step 4: Join Rocket.Chat

Rocket.Chat is a communication tool we use to engage with product teams and individuals in the B.C. public service who are building digital products. You can use Rocket.Chat to contact us, interact with teams working on the platform, get support, discover upcoming events and find solutions to common problems.

Learn how to join the B.C. government Rocket.Chat and what channels you should be posting to.

Step 5: OpenShift 101 training

Before you start your project, we provide OpenShift training to help you and your team get comfortable using the platform. There are 2 components to the training:

  • A one-day workshop for your whole team
  • A self-guided lab for developers

Your team must complete OpenShift 101 training before you can start building your application on the platform. An optional OpenShift 201 course is also available.

Step 6: Begin using the platform

Once your developers and DevOps specialists have completed the OpenShift lab, you’re ready to begin working on the platform.

To get started, you need to provision a new product in OpenShift.

Once your product provisioning request is processed, your product administrators (the product owner and the technical leads listed on the provisioning request) will be emailed a link to the OpenShift console. You can use this link to access your product namespaces. Product administrators can grant access to the namespaces as needed.

If you have any questions while getting set up on the platform, there are many ways to get support or help. You can also explore our technical documentation for more information.

Step 7: Plan for resiliency

Applications on the B.C. Government Private Cloud PaaS should meet resiliency guidelines, meaning they’re built for resiliency, reliability and continuous support. 

Resilient applications share a few characteristics, including:

  • Highly available
  • Easily deployed
  • Recoverable
  • Correctly resourced
  • Monitored

Learn how to configure your applications for resiliency and success on the B.C. Government Private Cloud PaaS.

Single- and multi-node deployment

The following definitions may help you better understand these 2 concepts and how they contribute to building resilient applications. 

  • A pod is the most basic deployable object in Kubernetes. Each pod holds a container that includes everything needed to run a single instance of your application. Pods run on nodes
  • A node is a machine that runs pods. There are several nodes in each cluster on the platform. When properly configured, OpenShift can manage nodes for you. It will scale pods across nodes or redeploy pods to new nodes, to make sure applications are running properly. You can deploy your application as either single- or multi-node, and it will behave differently depending on which method you choose
  • Single-node deployment means you are only deploying your application to one node in a cluster. It is not duplicated in any other nodes. Single-node deployment is most often used when testing a new application, because it is easier and faster to configure than multi-node deployment. However, if you use single-node deployment to run your application, your application is not considered highly available. This is because it is more susceptible to interruptions in availability
  • Multi-node deployment means you are deploying your application to several nodes in a cluster. As a result, your application is duplicated and running in several nodes at the same time. Multi-node deployment contributes to high availability for your application. This is because applications using multi-node deployment are less likely to experience interruptions in availability

Building resilient applications

Use these characteristics as guidelines as you build and deploy your own application in the B.C. Government Private Cloud PaaS. 

Highly available

The platform may have very high availability, but individual nodes do not. To prevent any negative impact to your application and increase the availability of your service, we recommend configuring your application for multi-node deployment.

Nodes are restarted or changed frequently, as we maintain and improve the platform’s physical infrastructure. If your developer configures your application for multi-node deployment, your application is already running on multiple nodes. If one node goes down for maintenance, it will not impact your application or service availability. We recommend multi-node deployment for this reason.

If your developer configures your application for single-node deployment, they should also configure the application so it can easily redeploy to another node, if the one it is running on goes down.

Learn how to configure your application for multi-node deployment in OpenShift.

Easily deployed

All applications in OpenShift should be built with the expectation that any node can be taken offline at any time. When this happens, your application should be easy to redeploy, with minimal impact to your service. This is critical if your application is configured for single-node deployment. 

When a node does go down, the platform redeploys your application to a pod in another node. The process to start up that new pod and redeploy your application should be quick and easy. For this to happen, all of your deployment configurations should be automated and clearly documented to ensure that they are easily accessible, consistent and up-to-date at all times. 

If OpenShift is missing any of the information it needs to redeploy your application, your application may experience an interruption in service until you are able to go online and resolve the issue. You can avoid this issue by setting up automated CI/CD pipelines for building and deploying your applications.

Recoverable

Eventually, you may need to recover your application, due to data corruption or another significant failure. It’s important that your application is configured so that you can recover it quickly and easily, to limit any interruptions to your service. 

Part of building a recoverable application is to have an application that is easy to deploy. But it’s also important that you have the ability to recover data or configurations that cannot be held in a repository. That can include databases or application passwords. We highly recommend storing all sensitive information such as database passwords using Vault Secrets Management. 

Correctly resourced

Resources in the B.C. Government Private Cloud PaaS are limited and shared by all applications hosted on the platform. Make sure your application is only using the resources it needs. This ensures that enough resources are available for your application and for other applications on the platform. 

You can define the amount of resources your application needs using requests and limits in your pods in OpenShift. 

Learn more about how to effectively manage your application resources.

Monitored

This platform is highly available, but applications can still experience outages. Platform maintenance, failures, network problems or issues in the design or implementation of your application can prevent your application from working properly. 

The best way to manage these issues is to monitor your application. 

You can use Sysdig Monitor to monitor the health, availability and resource usage of your application. We also post details about upcoming scheduled maintenance in the #devops-alerts channel in Rocket.Chat. 

Make sure you stay informed on your application’s status and any upcoming changes to the platform. It’s your responsibility to update or modify your application as needed to make sure there’s no interruption to your service.