CODEWITHSUNDEEP
kubernetesvisual-studio-codekubernetes-helmbitnamirancher
Nomnom
Nomnom

Reputation: 4835

Cannot attach visual studio code (remote) to WordPress Bitnami helm release pod (Kubernetes)

Getting the following when trying to attach visual studio code to a WordPress pod (using the kubernetes extension):

An error occurred attaching to the container

With the following showing up in the terminal:

[3 ms] Remote-Containers 0.166.0 in VS Code 1.55.0 (c185983a683d14c396952dd432459097bc7f757f).
[48 ms] Start: Resolving Remote
[51 ms] Start: Run: kubectl exec -it wp-test-2-wordpress-65859bfc97-qtr9w --namespace default --container wordpress -- /bin/sh -c VSCODE_REMOTE_CONTAINERS_SESSION='5875030e-bcef-47a6-ada5-7f69edb5d9091617678415893' /bin/sh
[56 ms] Start: Run in container: id -un
[279 ms] 1001
[279 ms] Unable to use a TTY - input is not a terminal or the right kind of file
id: cannot find name for user ID 1001
[279 ms] Exit code 1
[281 ms] Command in container failed: id -un

I have no such problem doing the exact same operation on any other helm release. Only with Bitnami WordPress helm releases.

Upvotes: 0

Views: 576

Answers (2)

Louis Cribbins
Louis Cribbins

Reputation: 189

I had a similar issue, but was trying to attach to an RShiny application in kubernetes. My error was showing this:

56 ms] Start: Run in container: id -un
[279 ms] 2000
id: cannot find name for user ID 2000

The solution that worked for me was to add a user with that number to my dockerfile, like so:

# add a user with id 2000 to allow vscode to access the container
RUN groupadd -g 1001 vscodegroup && useradd -u 2000 -g 1001 vscodeuser

Upvotes: 0

matt_j
matt_j

Reputation: 4614

That is because the Bitnami WordPress image (version 9.0.0) was migrated to a "non-root" user approach. From now on, both the container and the Apache daemon run as user 1001.

You can find more information in the Bitnami WordPress documentation:

The Bitnami WordPress image was migrated to a "non-root" user approach. Previously the container ran as the root user and the Apache daemon was started as the daemon user. From now on, both the container and the Apache daemon run as user 1001. You can revert this behavior by setting the parameters securityContext.runAsUser, and securityContext.fsGroup to 0. Chart labels and Ingress configuration were also adapted to follow the Helm charts best practices.

This problem occurs because running the id -un command inside the WordPress Pod causes error:

$ kubectl exec -it my-1-wordpress-756c595c9c-497xr -- bash
I have no name!@my-1-wordpress-756c595c9c-497xr:/$ id -un
id: cannot find name for user ID 1001

As a workaround, you can run WordPress as a root by setting the parameters securityContext.runAsUser, and securityContext.fsGroup to 0 as described in the Bitnami WordPress documentation.

For demonstration purposes, I only changed the containerSecurityContext.runAsUser parameter:

$ helm install --set containerSecurityContext.runAsUser=0 my-1 bitnami/wordpress

Then we can check the output of the id -un command:

$ kubectl exec -it my-1-wordpress-7c44f695ff-f9j9f -- bash
root@my-1-wordpress-7c44f695ff-f9j9f:/# id -un
root

As you can see, the id -un command doesn't cause any problems and therefore we can now successfully connect to the specific container.

I know this workaround is not ideal as there are many advantages to using non-root containers. Unfortunately, in this case, I don't know of any other workarounds without modifying the Dockerfile.

Upvotes: 1

Related Questions