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.
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.
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:
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 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 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
- Correctly resourced
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.
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.
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.
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.
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.
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.