Elastic
Loading

Air gapped install

ECK

Pending to determine what to do with this:

  • Syncing container images for ECK and all other Elastic Stack components over to a locally-accessible container repository.
  • Modifying the ECK helm chart configuration so that ECK is aware that it is supposed to use your offline container repository instead of the public Elastic repository.
  • Optionally, disabling ECK telemetry collection in the ECK helm chart. This configuration propagates to all other Elastic components, such as Kibana.
  • Building your custom deployment container image for the Elastic Artifact Registry.
  • Building your custom deployment container image for the Elastic Endpoint Artifact Repository.

The ECK operator can be run in an air-gapped environment without access to the open internet when it is configured not to pull container images from docker.elastic.co.

By default ECK does not require you to specify the container image for each Elastic Stack application you deploy.

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 8.16.1
 1
  nodeSets:
  - name: default
    count: 1
  # podTemplate:
  #   spec:
 2
  #     - name: private-registry-credentials-secret
  1. The ECK operator will set this value by default. You can explicitly set it to your mirrored container image when running in an air-gapped environment
  2. You can provide credentials to your private container registry by setting the imagePullSecrets field through the spec.podTemplate section of your Elastic resource specification, check how to customize the Elastic resources Pods and how to setup a Secret containing your registry credentials.

ECK will automatically set the correct container image for each application. When running in an air-gapped or offline environment you will have to mirror the official Elastic container images in a private container image registry. To make use of your mirrored images you can either set the image for each application explicitly as shown in the preceding example or more conveniently override the default container registry as explained in the next section.

To deploy the ECK operator in an air-gapped environment, you first have to mirror the operator image itself from docker.elastic.co to a private container registry, for example my.registry.

Once the ECK operator image is copied internally, replace the original image name docker.elastic.co/eck/eck-operator:2.16.1 with the private name of the image, for example my.registry/eck/eck-operator:2.16.1, in the operator manifests. When using Helm charts, replace the image.repository Helm value with, for example, my.registry/eck/eck-operator.

When creating custom resources (Elasticsearch, Kibana, APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash), the operator defaults to using container images pulled from the docker.elastic.co registry. If you are in an environment where external network access is restricted, you can configure the operator to use a different default container registry by starting the operator with the --container-registry command-line flag. Check Configure ECK for more information on how to configure the operator using command-line flags and environment variables.

The operator expects container images to be located at specific repositories in the default container registry. Make sure that your container images are stored in the right repositories and are tagged correctly with the Stack version number. For example, if your private registry is my.registry and you wish to deploy components from Stack version 8.16.1, the following image names should exist:

  • my.registry/elasticsearch/elasticsearch:8.16.1
  • my.registry/kibana/kibana:8.16.1
  • my.registry/apm/apm-server:8.16.1

If you cannot follow the default Elastic image repositories naming scheme, you can configure the operator to use a different container repository by starting the operator with the --container-repository command-line flag. Check Configure ECK for more information on how to configure the operator using command-line flags and environment variables.

For example, if your private registry is my.registry and all Elastic images are located under the elastic repository, the following image names should exist:

  • my.registry/elastic/elasticsearch:8.16.1
  • my.registry/elastic/kibana:8.16.1
  • my.registry/elastic/apm-server:8.16.1

The eck-diagnostics tool optionally runs diagnostics for Elastic Stack applications in a separate container that is deployed into the Kubernetes cluster.

In air-gapped environments with no access to the docker.elastic.co registry, you should copy the latest support-diagnostics container image to your internal image registry and then run the tool with the additional flag --diagnostic-image <custom-support-diagnostics-image-name>. To find out which support diagnostics container image matches your version of eck-diagnostics run the tool once without arguments and it will print the default image in use.

Setting up air-gapped Kubernetes or OpenShift installs of the Elastic Stack has some unique concerns, but the general dependencies are the same as in the self-managed install case on a regular Linux machine.

The Elastic Kubernetes operator is an additional component in the Kubernetes OpenShift install that, essentially, does a lot of the work in installing, configuring, and updating deployments of the Elastic Stack. For details, refer to the Elastic Cloud on Kubernetes install instructions.

The main requirements are:

  • Syncing container images for ECK and all other Elastic Stack components over to a locally-accessible container repository.
  • Modifying the ECK helm chart configuration so that ECK is aware that it is supposed to use your offline container repository instead of the public Elastic repository.
  • Optionally, disabling ECK telemetry collection in the ECK helm chart. This configuration propagates to all other Elastic components, such as Kibana.
  • Building your custom deployment container image for the Elastic Artifact Registry.
  • Building your custom deployment container image for the Elastic Endpoint Artifact Repository.

The container image can be downloaded from the official Elastic Docker repository, as described in the Fleet and Elastic Agent air-gapped environments documentation.

This container would, ideally, run as a Kubernetes deployment. Refer to Appendix C - EPR Kubernetes Deployment for examples.

A custom container would need to be created following similar instructions to setting up a web server in the self-managed install case. For example, a container file using an NGINX base image could be used to run a build similar to the example described in Appendix B - Elastic Artifact Registry.

Just like the Elastic Artifact Registry. A custom container needs to be created following similar instructions to setting up a web server for the self-managed install case.

Besides the public Elastic container repository, most Elastic Stack container images are also available in Platform One’s Iron Bank.