Skip to main content

Before you begin

Before you get started using Yalla IDP, let's get through a few quick steps to ensure the project is setup correctly.

Metadata​

All resources will be created inline with Application Package ID corresponding to the application in ServiceNow for the product's Technical Service. A quick start approach is available for Demo Apps and Greenfield Applications that are yet to be decided on their tenancy/ownership*.

For more info on how bp's Application Packages are structured in ServiceNow, please refer to ServiceNow

Understanding tenancy within Yalla​

Before you begin onboarding to Yalla, it's worth considering the best tenancy model for your application. Yalla has a federated model, where compute clusters and cloud services run in accounts owned and paid for by the product. For smaller products with lower consumption requirements, we offer a centralised platform known as multi-tenant.

If you are looking to try out Yalla and get running quickly, we recommend following the multi-tenant guide. You can create a federated platform later if desired.

Limitations​

Some of the services are not Publicly available (eg, JFrog Artifactory, SonarQube, Venafi, etc) and need ZScalar setup and an effort is in place to make them Publicly accessible.

Create a Git Repository​

If you don't have an ADO project/repository yet, let's get a repository created in CodeAlign ADO Project. Follow the instructions on Project landing page by creating a new branch from main in bp_ado_codealign repository and get the PR merged to provision all resources.

A quick resource and policy launch templates are available in base_schema directory

  1. Clone repository to your local → git clone url
  2. Create a branch from main → git switch -c <app-pkg-id>_resources
  3. Use reference templates and create ado_resources.yaml, ado_policies.yaml in your Application Packaged scoped directory under /resources
  4. Push your changes to the remote → git push origin <app-pkg-id>_resources
  5. Raise a Pull Request to merge your changes back into the main, a Validation Linter job ensures the config is as expected and resources will be created in the project.

Create a JFrog artifactory repository/registry​

Application needs a docker/oci compliant repository to push built images. Use this automation hub form to Create an Artifactory repository and pick the Application package details:

  • Instance: dml.bpglobal.com
  • Repo Type: local
  • Artifact Type: general
  • Package Type: docker
  • SNOW Activity: Technical Service
  • SNOW Application Package: <App Package>
  • Repo Name: Leave it to be generated automatically
  • Security Enabled AD/Entra ID Group: Entra ID group that needs the ability to push docker images from their local devices
  • Assign Build/Release Permissions: Yes

You should then get an email shortly that your repository has been created. It should say the name of the repository in the email that you receive. For example:

The local Artifactory repository "bp-<app-pkg-id>-docker-local" has been created.

Keep the repository name handy. You should now be able to log into BP JFrog Artifactory, and as long as you are a part of the AD group, you should be able to see this repository. There could be a slight delay with the group sync process and that might delay the permissions being applied, you can force a permission sync on the group using Sync Artifactory Group automation.

Yalla CLI​

The first thing you'll need to do is install the Yalla CLI, which is the entry point to onboarding to the platform. It also lets you manage secrets, deployments, and other parts of your platform.

You can validate that the CLI is installed and on your path correctly by running yalla --version:

~ yalla --version
yalla version a900b09217c9f0938573c8ab943113563170ccf7

Yalla Repository Structure​

A quick intro to how federated tenant and multi-tenant products are structured in Yalla repository before we deep dive into resource provisioning/bootstrap:

In Yalla, a product is a logical grouping of services. Since federated platforms are typically larger in scope, we offer this to organize services more easily within a platform. It can be named the same as the platform if you don't need this separation.

Root Structure​

/
├── infra/                       # Yalla Core Team managed
├── management-cluster/          # Yalla Core Team managed
├── multitenant/                 # Shared Cluster with Customer/s managed resources
├── platforms/                   # Federated Tenants with Customer/s managed resources
├── sandbox/                     # Sandbox resources
├── schema/                      # Schema to validate the templates files
├── tools/                       # Validation tools

Federated Tenancy​

/
├── platforms                         # Federated/BYO Cloud Tenant
│   ├── productA                      # Product (Logical Structure that encapsulate the services deployed)
│   │   └── platform.yaml             # platform.yaml generated through `yalla bootstrap`
│   │   ├── service1                  # Service 1 (Micro service that gets deployed to the cluster)
│   │   │   └── service.yaml          # service.yaml spec that defines the deployment strategy and its resources of Service 1
│   │   ├── service2                  # Service (Micro service that gets deployed to the cluster)
│   │   │   └── service.yaml          # service.yaml spec that defines the deployment strategy and its resources of Service 2
│   ├── productB
│   │   └── platform.yaml

Multi-Tenancy​

/
├── multitenant                       # Multitenant/Shared Cluster
│   ├── productA                      # Product (Logical Structure that encapsulate the services deployed)
│   │   └── platform.yaml             # platform.yaml generated through `yalla bootstrap`
│   │   ├── service1                  # Service 1 (Micro service that gets deployed to the cluster)
│   │   │   └── service.yaml          # service.yaml spec that defines the deployment strategy and its resources of Service 1
│   │   ├── service2                  # Service (Micro service that gets deployed to the cluster)
│   │   │   └── service.yaml          # service.yaml spec that defines the deployment strategy and its resources of Service 2
│   ├── productB
│   │   └── platform.yaml

Summary​

With this you have all the necessary resources to develop and deploy your application to Multi-tenant or Federated tenant. The following repositories act as a SoR for your application deployment.

Git Repositories​

  • Application Repository: https://dev.azure.com/bp-digital/CodeAlign/_git/<app_pkg_id>_<repository_name>
  • Yalla Repository: https://dev.azure.com/bp-digital/DevOps-SRE/_git/yalla

Docker Registry/Repository​

dml.bpglobal.com/bp-<app_pkg_id>-docker-local

In the following sections, we will explore how Yalla CLI can be used to bootstrap the platform in Federated tenancy that gives Grafana, Feature flag resources or deploy an application to multi-tenant using a few simple steps.