Skip to content

[Analysis] Deploying with non-centralized infra #10

@zelima

Description

@zelima

As a developer, who follows the README, I expect to be able to deploy ckan image without centralized infra, But I'm not

Acceptance Criteriea

  • Either I'm able to run CKAN instance without centralized infra
  • Or We depreciate it and keep only centralized

Tasks

  • Do analysis and try to figure out how to do it properly
  • Decide whether we should keep it or not
  • If no remove that part from README

Analysis

I've tried to deploy the ckan instance without centralized infra

If you haven't deployed the centralized infra - remove the useCentralizedInfra option

cca_helm_upgrade --install --set replicas=1 --set nginxReplicas=1 --set disableJobs=true --set noProbes=true

But some pods won't start

cca_kubectl get pods
--context minikube CKAN_NAMESPACE = first-instance
NAME                            READY   STATUS                       RESTARTS   AGE
ckan-5585ffdf6b-pj2bw           0/1     Init:0/2                     0          3m
datastore-db-798b77bd89-kxg9x   0/1     CreateContainerConfigError   0          3m
db-64cb545664-cj6qw             0/1     CreateContainerConfigError   0          3m
jobs-db-55c5c959cb-qmjt9        0/1     ContainerCreating            0          4m
nginx-97d597dfc-mvlgt           1/1     Running                      0          4m
redis-84c54c55c4-njxzj          0/1     ContainerCreating            0          4m
solr-64cc9b5b74-s8g28           0/1     Init:0/1                     0          3m

Kubectl describe pods:

  Normal   Scheduled  7m21s                   default-scheduler  Successfully assigned first-instance/datastore-db-798b77bd89-kxg9x to minikube
  Warning  Failed     4m57s (x12 over 7m16s)  kubelet, minikube  Error: secrets "ckan-env-vars" not found

So the reason is that secret ckan-env-vars does not exist. And there is not a single word about ckan-cloud-env in docs. Only place I found it is ckan-cloud-docker.

Q: How can I relate this 2 repos?

Create ckan-env-vars

So as it seems I have to work with ckan-cloud-docer as well. As it seems I need to have cca-operator running and is able to communicate with minkube. To do so I have to do the following according to README

pwd
/home/zelima/viderum/cco/ckan-cloud-docker

cat .docker-compose.override.yaml 
version: '3.2'
services:
  cca-operator:
    volumes:
    - /home/zelima/.kube:/root/.kube
    - /home/zelima/.minikube:/home/zelima/.minikube
    environment:
    - KUBE_CONTEXT=minikube

docker-compose build cca-operator && docker-compose run --rm cca-operator --help

.docker-compose.override.yaml does not seem to be working. I've tried to directly put volumes' values in docker-compose.yaml and it worked.

cat docker-compose.yaml | grep cca-operator: -A 16
  cca-operator:
    image: viderum/ckan-cloud-docker:cca-operator-latest
    build:
      context: cca-operator
    command: ./server.sh
    restart: always
    volumes:
    - /etc/ckan-cloud:/etc/ckan-cloud
    - /home/zelima/.kube:/root/.kube
    - /home/zelima/.minikube:/home/zelima/.minikube
    environment:
    - KUBE_CONTEXT=minikube
    ports:
    - "8022:22"
    networks:
    - cloud-management
    - ckan-multi

I can say it worked as I can get the nodes

docker-compose build cca-operator && docker-compose run --rm --entrypoint kubectl cca-operator get nodes

I was able create secrets as well. Run follwoing

cca-operator() {     kubectl --context minikube --namespace ${CKAN_NAMESPACE} run cca-operator             --image=viderum/ckan-cloud-docker:cca-operator-latest             --serviceaccount=ckan-${CKAN_NAMESPACE}-operator --attach --restart=Never --rm             "$@"; }

kubectl --context minikube -n $CKAN_NAMESPACE delete secret ckan-env-vars ckan-secrets

cca-operator initialize-ckan-env-vars ckan-env-vars

cca-operator initialize-ckan-secrets ckan-env-vars ckan-secrets

At this point all containers are now working fine execpt SOLR.

kubectl logs -f solr-64cc9b5b74-lqsmb -n first-instance -c permissions
chown: /opt/solr/server/solr/ckan/data: No such file or directory

seems like it's coming from here https://github.com/ViderumGlobal/ckan-cloud-helm/blob/master/ckan/templates/solr-deployment.yaml#L30-L31

Not sure why it assumes that directory should exist.

At this point, I'm quitting with non-centralized infra. After all, the cluster is controlled by ckan-cloud-helm and CCO, and there it's with centralized infra

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions