Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://sourcegraph.com/docs/admin/deploy/kubernetes/kustomize below:

Sourcegraph on Kubernetes with Kustomize

Best for large enterprises that require a multi-node, self-hosted solution and prefer to use the Kustomize deployment type.

Below is an overview of installing Sourcegraph on Kubernetes using Kustomize.

• kubectl (v1.19 or later) with Kustomize (built into kubectl in version >= 1.14)
• A Kubernetes cluster (v1.19 or later)

• Support for Persistent Volumes with SSDs
• You can optionally refer to our terraform configurations for setting up clusters on:
• Amazon Web Services EKS
• Azure AKS
• Google Cloud Platform GKE

Create a release branch from the default branch (or an available tag) in your local fork of the deploy-sourcegraph-k8s repository.

See the docs on reference repository for detailed instructions on creating a local fork.

  # Recommended: replace the URL with your private fork
  $ git clone https://github.com/sourcegraph/deploy-sourcegraph-k8s.git
  $ cd deploy-sourcegraph-k8s
  $ git checkout v6.6.2517 && git checkout -b release

Create a copy of the instances/template directory and rename it to instances/my-sourcegraph:

  $ cp -R instances/template instances/my-sourcegraph

In Kustomize, this directory is referred to as an

.

1. Rename the kustomization.template.yaml file in instances/my-sourcegraph to kustomization.yaml.

• The kustomization.yaml file is used to configure your Sourcegraph instance.

  $ mv instances/my-sourcegraph/kustomization.template.yaml instances/my-sourcegraph/kustomization.yaml

2. Rename the buildConfig.template.yaml file in instances/my-sourcegraph to buildConfig.yaml.

• The buildConfig.yaml file is used to configure components included in your kustomization file if required.

  $ mv instances/my-sourcegraph/buildConfig.template.yaml instances/my-sourcegraph/buildConfig.yaml

By default, the provided kustomization.yaml template deploys Sourcegraph into the ns-sourcegraph namespace.

If you intend to deploy Sourcegraph into a different namespace, replace ns-sourcegraph with the name of the existing namespace in your cluster, or set it to default to deploy into the default namespace.

# instances/my-sourcegraph/kustomization.yaml
namespace: sourcegraph

A storage class must be created and configured before deploying Sourcegraph. SSD storage is not required but is strongly recommended for optimal performance.

We recommend using a pre-configured storage class component for your cloud provider if you can create cluster-wide resources:

# instances/my-sourcegraph/kustomization.yaml
  components:
    # Select a component that corresponds to your cluster provider
    - ../../components/storage-class/aws/aws-ebs
    - ../../components/storage-class/aws/ebs-csi
    - ../../components/storage-class/azure
    - ../../components/storage-class/gke

See our configurations guide for the full list of available storage class components.

If you cannot create a new storage class and/or want to use an existing one with SSDs:

1. Include the storage-class/name-update component under the components list

# instances/my-sourcegraph/kustomization.yaml
components:
# This updates storageClassName to
# the STORAGECLASS_NAME value from buildConfig.yaml
- ../../components/storage-class/name-update

2. Input the storage class name by setting the value of STORAGECLASS_NAME in buildConfig.yaml.

For example, set STORAGECLASS_NAME=sourcegraph if sourcegraph is the name of an existing storage class:

# instances/my-sourcegraph/buildConfig.yaml
kind: ConfigMap
metadata:
name: sourcegraph-kustomize-build-config
data:
STORAGECLASS_NAME: sourcegraph # -- [ACTION] Update storage class name here

Skip this step to use the default storage class without SSD support for non-production environments. However, you must recreate the cluster with SSDs configured for production environments later.

Search performance will be severely impacted without SSDs provisioned.

Generate a new set of manifests locally using the configuration applied to the my-sourcegraph subdirectory without applying to the cluster.

$ kubectl kustomize instances/my-sourcegraph -o cluster.yaml

Review the generated manifests to ensure they match your intended configuration.

Apply the manifests from the output file cluster.yaml to your cluster:

$ kubectl apply --prune -l deploy=sourcegraph -f cluster.yaml

Monitor the deployment status to ensure all components are running properly.

$ kubectl get pods -A -o wide --watch

To verify that the deployment was successful, port-forward the frontend pod with the following command:

$ kubectl port-forward svc/sourcegraph-frontend 3080:30080

Then access your new Sourcegraph instance at http://localhost:3080 to proceed to the site-admin setup step.

$ open http://localhost:3080

After the initial deployment, additional configuration might be required for Sourcegraph to customize your deployment to suit your specific needs.

Common configurations that are strongly recommended for all Sourcegraph deployments:

• Enable the Sourcegraph monitoring stack
• Enable tracing
• Adjust resource allocations
• Adjust storage sizes
• Configure ingress
• Enable TLS

Other common configurations include:

• Set up an external PostgreSQL Database
• Set up SSH connection for cloning repositories

See the configuration guide for Kustomize for more configuration options.

• Scaling Sourcegraph on Kubernetes
• Examples of deploying Sourcegraph to the cloud provider listed below:
• Amazon EKS
• Google GKE
• Migration guide on migrating from deploy-sourcegraph to deploy-sourcegraph-k8s
• Other deployment options
• Troubleshooting

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4