ข้ามไปยังเนื้อหา

This is the Stable version of the documentation. The latest version is experimental and under active development. You can use the version selector in the top-right menu to switch versions for this specific page, or click here to go to the latest version's homepage.

Apply Opstella Core Configuration

เนื้อหานี้ยังไม่มีในภาษาของคุณ

Apply to Opstella Core with Management Admin Panel

Section titled “Apply to Opstella Core with Management Admin Panel”
  1. Go to Opstella Management Admin Panel opstella-backend.${BASE_DOMAIN}/admin

  2. Login with Opstella Core Credentials

  3. Go to Workers > Configs

  4. Add Config + (Top Right) and paste contents of opstella-backend-devopstool.yaml for devopstool kind and click Save in the buttom page

  5. Add Config + (Top Right) and paste contents of opstella-backend-tag-on-premise.yaml for tag kind and click Save in the buttom page

Register Kubernetes Clusters Records to New Table

Section titled “Register Kubernetes Clusters Records to New Table”
  1. Connect to 🟢 Management Kubernetes Cluster ; i.e w/ Kubeconfig File

    Ensure you have defined and loaded your Global Shell Variables as described in Shell Variables.

    Terminal window
    source $HOME/opstella-installation/shell-values/kubernetes/management_cluster.vars.sh
    Terminal window
    export KUBECONFIG="$HOME/opstella-installation/kubeconfigs/management_cluster.yaml"
  2. Use kubectl exec command to get into opstella-core-XXXXXXXXX-YYYYY container.

    Firstly, Get the name of Opstella Core (Back-end) Pod.

    Terminal window
    kubectl get pods --namespace opstella-system

    Change opstella-core-XXXXXXXXX-YYYYY to be the one you get from getting pods list.

    Terminal window
    kubectl exec -i -t --namespace opstella-system pod/opstella-core-XXXXXXXXX-YYYYY -- sh
  3. Run Command

    Terminal window
    python manage.py migrate_opstella_v5
  4. Go back to Opstella Management Admin Panel opstella-backend.${BASE_DOMAIN}/admin

  5. Go to Workers > Kubernetes clusters, you will see a list of your Kubernetes Clusters configured to managed with Opstella.

  6. Click EACH of the record and assign Cluster group and Cluster category accordingly.

    • 🟦 Non-Production DEV Workload Kubernetes Cluster
      • Cluster group: NON-PRODUCTION
      • Cluster category: WORKLOAD
    • 🟥 Production PRD Workload Kubernetes Cluster
      • Cluster group: PRODUCTION
      • Cluster category: WORKLOAD
    • 🟢 Management Kubernetes Cluster
      • Cluster group: NON-PRODUCTION
      • Cluster category: DEVOPS

    Click Save on EACH of them.

  1. Go to Workers > Dev ops tool tags > Add dev ops tool tag + (Top Right)

  2. Select/Specify the following

    • Devops tool: keycloak

    • Tag: on-premise

    • Env: ["DEV", "SIT", "UAT", "PREPRD", "PRD"] (In case where you have 5 Environments in Opstella)

      • This text will need to be change ONLY IF you will have different number of Environments managed by Opstella
      • For instance, you only have 3 Environments managed by Opstella (DEV, PRE, PRD)
        • This field will be ["DEV", "PREPRD", "PRD"]

  3. Click Save on the bottom right

  1. Go to Tenant > Companys ; You should see a record of your organization name, having PROCESSING Status.

  2. Tick ✅ on the record of your organization name.

  3. The record of your organization name should soon have the Status of ACTIVE; Try refresh the page if it is not changing.

After applying the Config: publish the credentials to the state store

Section titled “After applying the Config: publish the credentials to the state store”

Applying the Config writes the DevOpsTool records, but the workers read each tool’s credentials from the Dapr state store, which is only written when a record is saved. Until then the state store has no core-credential-* keys and the first task each worker picks up fails.

Re-save every record once:

Terminal window
kubectl exec -i -t --namespace opstella-system deploy/opstella-core -- \
python manage.py shell -c "
from worker.models import DevOpsTool
for d in DevOpsTool.objects.all().order_by('id'):
d.save()
print('re-saved', DevOpsTool.objects.count())
"

Troubleshooting: the Company stays PROCESSING

Section titled “Troubleshooting: the Company stays PROCESSING”

Synchronisation is all-or-nothing. Task.manager.check_task_all_completed compares the number of completed tasks against DevOpsTool.objects.filter(status="COMPLETED").count(), and the batch is built from that same filter — so one tool the workers cannot reach keeps the Company in PROCESSING forever. There is no timeout and the Admin Panel shows no error.

Find which tool did not finish:

Terminal window
kubectl exec -i -t --namespace opstella-system deploy/opstella-core -- \
python manage.py shell -c "
from worker.models import Task, DevOpsTool
print('tools :', DevOpsTool.objects.filter(status='COMPLETED').count())
for t in Task.objects.order_by('-id')[:20]:
print(t.id, t.method, t.status, t.request_slug)
"

Then either fix the connectivity to that tool and synchronise again, or take it out of the batch temporarily by setting its status to WAITING:

Terminal window
kubectl exec -i -t --namespace opstella-system deploy/opstella-core -- \
python manage.py shell -c "
from worker.models import DevOpsTool
d = DevOpsTool.objects.get(name='CHANGEME'); d.status = 'WAITING'; d.save()
"

Every step on this page is written against the Admin Panel. If the Ingress, DNS or certificate for opstella-backend.${BASE_DOMAIN} is not in place yet, the same work can be done through manage.py shell as shown above.

A kubectl port-forward to the Admin Panel is not an equivalent: Django compares the request Origin against CSRF_TRUSTED_ORIGINS, which is derived from BASE_DOMAIN, so logging in over http://127.0.0.1:<port> fails CSRF validation.

Finished?

Use the below navigation to proceed