Laiki

Resources

ShinyProxy

ShinyProxyTarget

As explained in the deployment docs, you must first deploy the ShinyProxy Operator before using the Laiki Operator.

Once the ShinyProxy Operator is running, you can create a ShinyProxy configuration by defining a ShinyProxyTarget:

# input/shinyproxy.yaml
laiki-metadata:
  target-type: ShinyProxyTarget
  name: shinyproxy
  namespace: shinyproxy
laiki-spec:
  # normal ShinyProxy config

The name and namespace fields determine the name and namespace of the ShinyProxy custom resource in Kubernetes. You can deploy multiple ShinyProxy instances by creating additional ShinyProxyTarget files with different name and/or namespace values.

The spec is passed directly to the ShinyProxy Operator without modification.

ShinyProxyApp

To add applications to a ShinyProxy instance, create ShinyProxyApp resources:

# input/shiny-demo.yaml
laiki-metadata:
  resource-type: ShinyProxyApp
  target-name: shinyproxy
  target-namespace: shinyproxy
laiki-spec:
  id: shiny-demo
  container-image: openanalytics/shinyproxy-shiny-demo-minimal

The target-name and target-namespace must match an existing ShinyProxyTarget. This binds the app to a specific ShinyProxy instance. When multiple ShinyProxy instances are deployed, each app is bound to exactly one instance.

In addition to the standard ShinyProxy configuration values, Laiki supports the following optional properties:

order: integer to control the order of apps on the ShinyProxy landing page. Apps with lower values appear first. Example:

# input/shiny-demo.yaml
laiki-metadata:
  resource-type: ShinyProxyApp
  target-name: shinyproxy
  target-namespace: shinyproxy
laiki-spec:
  id: shiny-demo
  container-image: openanalytics/shinyproxy-shiny-demo-minimal
  order: 100

container-tags: a list of container image tags that adds a parameter allowing users to select a tag at runtime. Example:

# input/shiny-demo.yaml
laiki-metadata:
  resource-type: ShinyProxyApp
  target-name: shinyproxy
  target-namespace: shinyproxy
laiki-spec:
  id: shiny-demo
  container-image: openanalytics/shinyproxy-shiny-demo-minimal
  container-tags:
    default-tag: mytag
    tags:
      - name: MyTag
        tag: mytag
      - name: MyTag2
        tag: mytag2
      - name: MyTag3
        tag: mytag3

crane-data-repository: enables access to a Crane data repository in a ShinyProxy app by mounting a subdirectory from a shared volume. Requires configuring a pre-processor to specify the PVC:
```
# input/CraneRepositoryForShinyProxyAppPreProcessor.yaml
laiki-metadata:
  pre-processor-name: CraneRepositoryForShinyProxyAppPreProcessor
  name: shinyproxy
  target-namespace: shinyproxy
laiki-spec:
  crane-pvc-name: crane-storage 
```
This specifies the name of an existing PVC to use. Here's a complete ShinyProxyApp example:
```
laiki-spec:
  id: shiny-demo
  container-image: openanalytics/shinyproxy-shiny-demo-minimal
  crane-data-repository:
    mount-read-only: true
    write-access:
      users:
        - jack
    read-access:
      users:
        - jack
```
With this configuration, ShinyProxy mounts the shiny-demo (the id of the app) subdirectory of the crane-storage PVC (defined in the pre-processor) at /mnt/data inside the app container. If mount-read-only is true, the mount is read-only. If a matching CraneTarget is available, a repository is added to it as well. Using the Crane web UI, user jack will have both read and write access to this repository.

Crane

First, deploy Crane on Kubernetes.

Once deployed, Laiki can update Crane's ConfigMap and restart its deployment. Crane's configuration is managed using a CraneTarget:

# input/crane.yaml
laiki-metadata:
  target-type: CraneTarget
  name: crane 
  namespace: shinyproxy
laiki-spec:
  # normal Crane config

This minimal configuration is sufficient to use Crane with the crane-data-repository option in ShinyProxyApp.

CraneReport

A CraneReport enables you to host reports or static websites in a Crane repository. While these can be uploaded directly, using a CraneReport resource lets you define access control and other configurations declaratively.

# input/demo-report.yaml
laiki-metadata:
  resource-type: CraneReport
  target-name: crane
  target-namespace: shinyproxy
laiki-spec:
  name: demo-report
  repository: reports
  read-access:
    groups:
      - MyAccessGroups
    users:
      - jack
  write-access:
    users:
      - jack

This creates a directory (known as a path in Crane) inside the reports repository. The name and repository fields are used by Laiki to identify the report, while read-access and write-access are standard Crane access control properties.

By adding the add-to-shinyproxy: true property, Laiki automatically adds a link to the report in the ShinyProxy landing page. Additional ShinyProxy options can be specified as well:

# input/demo-report.yaml
laiki-metadata:
  resource-type: CraneReport
  target-name: crane
  target-namespace: shinyproxy
laiki-spec:
  name: demo-report
  repository: reports
  display-name: Demo report # ShinyProxy option
  template-group: Reports # ShinyProxy option
  read-access:
    groups:
      - MyAccessGroups
    users:
      - jack
  write-access:
    users:
      - jack

AWS ECR Repository

This module lets you manage Docker repositories in AWS Elastic Container Registry (ECR).

First, define an AwsEcrRepositoryTarget:

# input/ecr.yaml
laiki-metadata:
  target-type: AwsEcrRepositoryTarget
  name: ecr
  namespace: ecr
laiki-spec:
  prefix: "my/prefix/"
  tag-mutability: "immutable"
  lifecycle-policy: {
    "rules": [
      {
        "rulePriority": 1,
        "description": "Remove untagged images",
        "selection":
          {
            "tagStatus": "untagged",
            "countType": "sinceImagePushed",
            "countUnit": "days",
            "countNumber": 7
          },
        "action": {
          "type": "expire"
        }
      }
    ]
  }

The target supports these properties:

prefix: a prefix added to each repository name (use prefix: "" for no prefix)
tag-mutability: optional; controls tag mutability (immutable or mutable)
lifecycle-policy: optional; an ECR lifecycle policy applied to every repository

The Laiki Operator requires AWS permissions to manage repositories. It supports all common AWS authentication methods, including IRSA and EC2 instance metadata.

On each run, Laiki validates the configuration of existing repositories. If any settings differ from the configuration, Laiki updates them in AWS. For example, if the tag-mutability setting in AWS doesn't match the configured value, Laiki corrects it.

Finally, create an AwsEcrRepository resource to create a repository:

# input/my-repository-name.yaml
laiki-metadata:
  resource-type: AwsEcrRepository
  target-name: ecr
  target-namespace: ecr
laiki-spec:
  name: my-repository-name