Skip to content

Latest commit

 

History

History
185 lines (146 loc) · 7.91 KB

install-landscaper-controller.md

File metadata and controls

185 lines (146 loc) · 7.91 KB

Installation and Configuration of Landscaper

This document describes the installation of Landscaper.

Installation

Option 1: Installation via the landscaper-cli tool

The easiest way to install the landscaper with its default deployer is to use the landscaper-cli. The corresponding documentation can be found here.

Option 2: Installation via helm

Alternatively, the landscaper can also be installed via helm using the helm chart in charts/landscaper.

⚠️ Attention: There were some major changes to helm's OCI features with version v3.7.0. This guide uses the new version. If you want to use a version of helm older than v3.7.0, make sure you have export HELM_EXPERIMENTAL_OCI=1 set and use helm chart push, helm chart pull, and helm chart save instead of helm push, helm pull, and helm package respectively.

kubectl create namespace ls-system
helm install -n ls-system landscaper ./charts/landscaper

We are also building OCI charts so a specific version of Landscaper can be installed with:

export LS_VERSION="v0.15.0" # use the latest available version
helm pull oci://eu.gcr.io/gardener-project/landscaper/charts/landscaper --version $LS_VERSION
tar -xvf landscaper-v0.15.0.tgz
helm install -n ls-system landscaper ./landscaper

Landscaper's Helm chart can be configured with a values file.

In case of an OCI registry that is not exposed via https, the allowPlainHttpRegistries flag can be used. In case of an OCI registry using certificates signed by a custom certificate authority, the corresponding certificate authority certificate can be added to the landscapers truststore.

Note: Landscaper offloads all deployment specific functionality like deploying Helm charts to deployers. By default, the Landscaper deployment contains no deployer, so you are unable to reconcile any deploy items. But a subset of internal open-source deployers (helm, manifest and container) can be automatically configured. See below for more details.

Configuration through values.yaml

The following snippet shows a sample values.yaml file that is used to parameterize the Helm chart:

landscaper:
    controller:
      image:
        tag: image version # .e.g. 0.0.0-dev-8bf4b8150f96fed8868618c56787b81fa4e095e6
    
    webhookServer:
    #  disableWebhooks: all # disables specific webhooks. If all are disabled the webhook server is not deployed
      image:
        tag: image version # .e.g. 0.0.0-dev-8bf4b8150f96fed8868618c56787b81fa4e095e6
    
    landscaper:
      cache: {} # Landscaper caches pulled OCI artefacts on disk and optionally in-memory
    #     useInMemoryOverly: false
      truststore:  # can be used to add certificates to the trust store of the landscaper
        secrets: {} # contains certificates (optionally in a single or multiple secrets)
      registryConfig:
        allowPlainHttpRegistries: false
        secrets: # contains optional oci secrets
          default: {
            "auths": {
              "hostname": {
                "auth": "my auth"
              }
            }
          }
      metrics:
        port: 8080  
        
      # tell the landscaper to use the new ocm tooling to process components     
      # if you use the ocm-cli to create components you likely want this to be set to true
      # if you use the deprecated component-cli to create components you likely want this to be set to false
      useOCM: true # current default: false    
      
      # deploy with integrated deployers for quick start
      deployers: 
      - container
      - helm
      - mock
      - manifest 

Landscaper image and tag

If Landscaper is installed with a local copy of the Helm chart, the field image.tag has to be defined to specify which container image for Landscaper should be used.

If Landscaper is installed through an OCI chart, the image tag will automatically be matched with the given version.

Private registry access

Blueprints and component descriptors must reside in one or more OCI registries. During an installation process, Landscaper attempts to pull them from there.

If component descriptors or blueprints are stored in a non-public OCI registry, the registry's secrets can be provided in the landscaper.landscaper.registrySecrets section by providing a map of <config-name>: <docker auth>. Different sets of secrets can be provided for blueprints and component descriptors by the landscaper.landscaper.registrySecrets.blueprint and landscaper.landscaper.registrySecrets.components fields respectively.

The value to provide to <docker auth> must be a Docker auth config as plain JSON (not as a string). Refer to Kubernetes' pull-secret documentation for a comprehensive guide.

Caching

Landscaper allocates some temporary disk space to cache OCI artefact it pulls. Optionally, artefacts can be cached in-memory as well.

Metrics

Landscaper is instrumented to collect the default metrics of the controller-runtimes. Additionally, it serves some custom metrics e.g. for its OCI cache. The metrics may be scraped at /metrics and a configurable port defaulting to 8080.

Internal and external deployers

Landscaper offloads all deployment specific logic (e.g. helm) to external deployers that are deployed to a target cluster.

For a very simple setup, internal deployers (helm, manifest and container) can be served by Landscaper.

The default deployers are deployed using the Landscaper integrated Deployer Lifecycle Management that are configured with the opensource images and basic defaults.

The default configuration can be overwritten or enhanced by supplying deployerConfig in the values.yaml. See the specific helm chart values of the deployer for detailed documentation.

landscaper:
    landscaper:
      deployers: [container, helm]
      deployersConfig:
        Deployers:
          # match the deployer name
          container:
            deployer:
              # provide any helm charts values.
              oci:
                allowPlainHttp: false
          helm:
            deployer:
              # ...

Additional external deployer can be either configured by applying the DeployerRegistration directly or providing the Registration in the helm chart.

Note: When the registration is provided through the helm chart, all defaults of the "default" environment are automatically injected (if not overwritten in the registration).

For detailed information about the DeployerRegistration and its configurations see the documentation or the example.

landscaper:
    landscaper:
      deployers: [my-custom-deployer] # the external deployer name MUST be set.
      deployersConfig:
        # match the deployer name
        my-custom-deployer: 
          apiVersion: landscaper.gardener.cloud/v1alpha1
          kind: DeployerRegistration
          metadata:
            name: my-deployer # defaulted to "my-custom-deployer"
            
          spec:
            # describe the deploy items types the deployer is able to reconcile
            types: ["my-deploy-item-type"]
            installationTemplate: # note that no exports are allowed here.
              componentDescriptor:
                ref:
                  repositoryContext:
                    type: ociRegistry
                    baseUrl: "example.myregistry.com/my-context"
                  componentName: "my-custom-deployer"
                  version: v1.0.0
    
              blueprint:
                ref:
                  resourceName: my-deployer-blueprint
          ...