Services

Setup Services

If you've followed the guidance in the previous pages, you should now have a platform.yaml setup on Yalla, like this:

├── platforms
│   ├── accelerate
│   │   └── platform.yaml

Next, we'll setup a new service.

Setting up a product directory (Federated)

If you created a federated platform, you should first setup a folder for the product.

Reminder: What is a product? 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.

├── platforms
│   ├── accelerate
│   │   ├── platform.yaml
│   │   └── products
│   │       └── accelerate
│   │           └── services

Setting up service.yaml

Start by creating a service.yaml file under the services directory within your product (federated) or platform (multi-tenant).

At a minimum, you should specify the name of your app, ports, deployment requests and limits and probes for your app.

New to Kubernetes? We recommend reading up on:

• Configure Liveness, Readiness and Startup Probes
• Resource Management for Pods and Containers

serviceTargeting:        # Mandatory for multitenant. Ignored for federated.
  regions:
  - eu-west-1            # Specify the multitenant region you want to deploy the service into (eu-west-1 or us-east-1 only)

service:
  name: codehub
  namespace: accelerate
  ports:
  - name: http
    port: 80
    targetPort: 3000
  deployment:
    containers:
      app:
        ports:
        - name: http
          port: 3000
        resources:
          limits:
            memory: 2Gi
          requests:
            cpu: 20m
            memory: 192Mi
        livenessProbe:
          httpGet:
            path: /health-check
            port: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: http
        startupProbe:
          httpGet:
            path: /readiness
            port: http

Setting up your environment-specific values.yaml

Once you have a service file created, you can now create environment-specific overrides in <env>/values.yaml. At a minimum, you should specify the tag for the OCI image you need to deploy.

If your service needs an internal or external HTTP endpoint specified, you can list that too. A DNS record and TLS certificate will be provisioned automatically.

For multi-tenant, you should specify a domain that ends in:

• yalla-staging.bpaws.com (staging)
• yalla-prod.bpaws.com (prod internal)
• yallapp.bpglobal.com (prod external)

Supported domains: Currently, Yalla can automatically provision bpaws.com subdomains. Work is underway for bpweb.bp.com and bpglobal.com support in federated platforms. Multi-tenant users can use *.yallapp.bpglobal.com.

service:
  deployment:
    containers:
      app:
        image:
          ref: dml.bpglobal.com/bp-accelerate-docker-images-release-local/accelerate-hello-yalla@sha256:5557b50728e5f69c614c4f73ef6da846ba00078f4e66fa504261c20f289d6b6a
  endpoints:
    internal:
      hosts:
      - yalla-demo.internal.accelerate-int.bpaws.com
      port: http

If your application runs on a port other than 8080, you can override the http port:

service:
  ports:
  - name: http
    port: 3000

Why is the image ref in values.yaml? Following 12 factor app best practices, you should build a single image for all environments. However, we recommend using an automated deployment flow that promotes your image to each environment only after the deployment to the preceding environment has completed successfully. Therefore, we keep the image configuration at the environment level. Have a look at the automated commits in the Yalla commit history to see how this works.

Environment variables

There are three ways to expose environment variables:

Environment and service specific

Any non-sensitive environment variables for an application, in a specific environment can be exposed in the values.yaml file:

service:
  env:
    MY_ENV_SPECIFIC_VAR: value

Service specific

Any non-sensitive environment variables that are shared between all environments in a specific application can be exposed directly in the service.yaml file:

service:
  env:
    MY_APP_VAR: value

Environment specific

If you have environment variables that you want to share across an entire suite of services for a particular environment, you can create an envs directory with a services.common.yaml file within your platform:

├── platforms
│   ├── accelerate
│   │   ├── envs
│   │   │   ├── infra.shared.yaml
│   │   │   ├── int
│   │   │   │   ├── infra.shared.yaml
│   │   │   │   └── services.common.yaml
│   │   │   └── prod
│   │   │       ├── infra.shared.yaml
│   │   │       └── services.common.yaml
│   │   ├── platform.yaml
│   │   └── products
│   │       └── accelerate
│   │           └── services

Secrets

Secrets in Yalla are stored in AWS Secrets Manager. The Yalla CLI is the easiest way to manage secrets. Once stored in secrets manager, they will be automatically exposed as environment variables in the deployment pods. Any changes to secrets will trigger a rolling restart of the pods within 5 minutes.

Multi-tenant

~ yalla secret create --tenant accelerate --service test --env staging --key TEST_VAR --value test_value
2025/04/23 16:44:01 Secret updated: accelerate/staging/apps/test/TEST_VAR

Federated

~ yalla secret create --platform accelerate --service test --env staging --key TEST_VAR2 --value test_value
2025/04/23 16:44:01 Secret updated: accelerate/int/apps/test/TEST_VAR2

Viewing the service in ArgoCD

If you merge your changes at this point, you should be able to see your application state in ArgoCD by searching for the app name and environment, e.g. yalla-secrets-prod-ew1 for the production yalla-secrets service running in AWS region eu-west-1.

If your application looks unhealthy, look at the logs and events in the pods to try and determine the problem.

Additional Cloud Services

Yalla uses Crossplane as a mechanism for managing cloud infrastructure as code. Crossplane is similar to tools like AWS CDK or Terraform, except it runs as a controller on Kubernetes.

The Yalla team maintain a suite of common infrastructure "compositions", such as S3 Buckets, DynamoDB tables and SNS topics. These are tailored to bp best practices and offer:

• Automatic access management, so that your app can access infrastructure via pre-made AWS IAM policies
• Connection details exposed via environment variables, e.g. PRODUCTS_SQS_QUEUE_URL

Service level infrastructure

To deploy infrastructure for a service, use the infra directive within service.yaml:

infra:
  resources:
    "demo-bp-bucket":
      type: BPS3Bucket

Available infrastructure types: To see the currently supported infrastructure types and their parameters, view the APIs in the Yalla infrastructure catalogue.

Once merged, the example above will create the bucket and inject the connection details:

DEMO_BP_BUCKET_BUCKET_ID
DEMO_BP_BUCKET_BUCKET_ARN
DEMO_BP_BUCKET_BUCKET_REGION

Shared infrastructure

If you want to share infrastructure between services, use an infra.shared.yaml file in the envs folder.

Importing existing infrastructure

You may want to bring an external resource under Crossplane / Yalla control using the external name annotation:

infra:
  resources:
    deployments:
      type: BPDynamoDB
      metadata:
        annotations:
          crossplane.io/external-name: YallaDeployments

Next Steps

Next, you should setup an automated deployment flow for your application.