Some experiences with your Playground - Demo on local machine

Hello Cloudogu-Team,

this post is regarding some experiences I saw using your Gitops Playground. I used Kubuntu Desktop version of Ubuntu, as I still prefer using KDE.

Environment:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS

The Ubuntu system has following packages installed: docker-ce, docker-ce-cli, containerd.io, curl, ssh, ntp, tigervnc-server, lsb-release, gnupg, ca-certificates, apt-transport-https

It seems that the playground will not work if I´ll follow your manual step by step without thinking:

1. Create Cluster:
bash <(curl -s
https://raw.githubusercontent.com/cloudogu/gitops-playground/main/scripts/init-cluster.sh)

As I did not find any specific information, I ran that command as a standard user. The result:

$bash <(curl -s https://raw.githubusercontent.com/cloudogu/gitops-playground/main/scripts/init-cluster.sh)
Initializing k3d-cluster ‘gitops-playground’
INFO[0000] Hostnetwork selected - disabling injection of docker host into the cluster, server load balancer and setting the api port to the k3s default
ERRO[0000] Failed to get nodes for cluster ‘gitops-playground’
INFO[0000] Prep: Network
ERRO[0000] Failed to list docker networks
ERRO[0000] Failed to check for duplicate networks
ERRO[0000] Failed to create cluster network
ERRO[0000] Failed Cluster Preparation: Failed Network Preparation: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get “http://%2Fvar%2Frun%2Fdocker.sock/v1.24/networks?filters=%7B%22name%22%3A%7B%22%5E%2F%3Fhost%24%22%3Atrue%7D%7D”: dial unix /var/run/docker.sock: connect: permission denied
ERRO[0000] Failed to create cluster >>> Rolling Back
INFO[0000] Deleting cluster ‘gitops-playground’
ERRO[0000] Failed to get nodes for cluster ‘gitops-playground’
ERRO[0000] No nodes found for given cluster
FATA[0000] Cluster creation FAILED, also FAILED to rollback changes!

OK, easy going - either using root up here, or adding the user to docker group I thought:

#usermod -aG docker playground
#sudo su - playground

$bash <(curl -s https://raw.githubusercontent.com/cloudogu/gitops-playground/main/scripts/init-cluster.sh)
Initializing k3d-cluster ‘gitops-playground’
INFO[0000] Hostnetwork selected - disabling injection of docker host into the cluster, server load balancer and setting the api port to the k3s default
INFO[0000] Prep: Network
INFO[0000] Re-using existing network ‘host’ (4aae9556c61094cf3b096b2389b0cc3f40827985db2b104a593bcc4bc23cfd5d)
INFO[0000] Created volume ‘k3d-gitops-playground-images’
INFO[0001] Creating node ‘k3d-gitops-playground-server-0’
INFO[0001] Starting cluster ‘gitops-playground’
INFO[0001] Starting servers…
INFO[0001] Starting Node ‘k3d-gitops-playground-server-0’
INFO[0011] Starting agents…
INFO[0011] Starting helpers…
INFO[0011] Cluster ‘gitops-playground’ created successfully!
INFO[0011] --kubeconfig-update-default=false → sets --kubeconfig-switch-context=false
INFO[0012] You can now use it like this:
kubectl config use-context k3d-gitops-playground
kubectl cluster-info
Adding k3d cluster to ~/.kube/config

Followed your information to run e.g. kubectl cluster-info:
$kubectl cluster
kubectl: command not found

:(, So I did:

#curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
#echo “deb https://apt.kubernetes.io/ kubernetes-xenial main” | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
#apt-get update
#apt-get install -y kubectl

Now, I can use the information lines to get an overview about the cluster.
Next step.

2. Apply Playground:

$docker run --rm -it -v ~/.k3d/kubeconfig-${CLUSTER_NAME}.yaml:/home/.kube/config --net=host ghcr.io/cloudogu/gitops-playground
error: error loading config file “/home/.kube/config”: open /home/.kube/config: permission denied
Applying gitops playground to kubernetes cluster: ‘’.
Continue? y/n [n]

After thinking a bit and switching into the container I started, I became aware, that you are expecting running that docker run with UID 1000. But this is neither the case if I´ll run that command as root user, or in my case using another UID as my test user “playground” has a higher ID.

So, maybe it´ll make sense to add an information to make sure that the file ~/homedir/user/.k3d/kubeconfig-… has the ownership 1000:0, as 1000 is the expected UID inside the container:

~/.k3d$ ll -n
total 12
drwxrwxr-x 2 1001 1001 4096 Okt 5 17:09 ./
drwxr-xr-x 5 1001 1001 4096 Okt 5 16:49 …/
-rw------- 1 1000 0 3063 Okt 5 17:09 kubeconfig-gitops-playground.yaml

Here we go…
$docker run -it -v ~/.k3d/kubeconfig-${CLUSTER_NAME}.yaml:/home/.kube/config --net=host ghcr.io/cloudogu/gitops-playground
Applying gitops playground to kubernetes cluster: ‘k3d-gitops-playground’.
Continue? y/n [n]
y
Full log output is appended to /tmp/playground-log-XXXAhgene
[ok] Basic setup & configuring registry…
…progressing…

As I see some further issues within Jenkins as well, I´ll using another docker run command up from here.
Therefore, please find some more lines regarding my experiences in “GitOps Playground: no jobs shown in Jenkins” in some minutes as well.
I found there the information how to keep the logs, so I didn´t start with --rm already, but will do the debug piece as well.

Cheers,
Sascha

Hi Sascha,

Thanks very much for taking the time to compile this extensive feedback.

I put together some quick fixes, basing on your feedback. What do you think?

Some more background:

We used to install kubectl on cluster init, but not everyone needs it, or might have a different version installed, which we didn’t want to mess with.

The line regarding “cluster-info” is printed by k3d (the local kubernetes cluster we’re using). I just suppressed it, resulting in an output as simple as this:

Initializing k3d-cluster 'gitops-playground'
Cluster 'gitops-playground' already exists. Do you want to recreate the cluster?
[y/N]
y
Deleting cluster gitops-playground
Creating cluster gitops-playground
Adding k3d cluster to ~/.kube/config

To avoid issues with the classical assumption that everyone runs as UID 1000 I adopted the docker run command to run as the current UID: docker run -u $(id -u) .. which should fix your issue.

Also I added a command for printing out the debug log to the README.

If you have concrete ideas on how to improve the playground or its docs, please don’t hesitate to open any pull requests. Always happy to get contributions!

Hi Johannes,

:smiley: as always … someones need it, the other ones don´t like it and the last ones hate it…
Yeah, understand your point regarding the kubectl package or version.
Maybe a hint were to find it would be enough? A link to the kubernetes page might help out here, I guess. It was just an idea. But hey, funny to see that it had been discussed vice versa already.

Regarding using the id output. That i also thought about. But as you don´t give exact information which user to user, and the situation you could run into not to have the user inside the docker group, the user maybe uses root running the docker command. Well yes, we are talking about a playground. But if root rights are not needed, why using root rights inside the container potentially, what do you think about it?

Just thinking, maybe it is enough to write a line about that a normal user is enough to run that thing in combination with the id output in the docker command line.

Will keep the offer to contribute in my mind :wink:.

Many thanks and best regards,
Sascha

1 Like

Hi Sascha,

I had another go at the docs, adding kubectl and docker group info. I hope that’s what you meant.
If not, please suggest concrete changes in the READMEs here or via GitHub.
Thanks,

Johannes

BTW - I also made our script trigger Jenkins’ Scan now functionality for each job, so the jobs should now show automatically. This might also be related to the other topic you referred to (No jobs shown in Jenkins).

Hi Johannes,

my apologies answering a bit late, but the last days were rather busy.

Yes, I guess these links or additional information will help others in case having trouble which user to use or run into a situation not using UID 1000.

Just ran thru all the steps again with a clean docker situation (removed all images and volumes). Used UID1001 just to double check the behavior. Works absolutely fine for me.
Many thanks pushing the changes forward. Hope that they will be helpful.

Will now also look into the other topic “No jobs shown in Jenkins”.

Best regards,
Sascha