For ease of deployment, but without wanting to dive straight into Helm (just yet), I decided to try to stand up a very simple \/ crude Kubernetes deployment based on Jenkins. Needless to say, it wasn’t as simple as I’d hoped: I ran into a number of permission related problems.<\/p>\n\n\n\n
On first pass, I got a log message which said that the Jenkins didn’t have permission to write to \/var\/jenkins_home\/copy_reference_file.log. This post<\/a> suggested a quick and easy fix, which was to run the container as root. This translates to a runAsUser 0 in a securityContext definition. And, per the recommendation (which includes caveats), the permission problem went away. While the pod started correctly, I then started having persistent problems with the connection refused, even when I tried on localhost from within the container. I suspected (possibly incorrectly) this was related to the root perms, so based on this issue<\/a>, removed the block, deleted everything under the persistent volume that was already installed, and chown’ed to 1000 (which is the ubuntu user). This fixed the perms problem, but I was still getting a connection refused.<\/p>\n\n\n\n What I suspect was the problem was that I was trying to map a loadBalancer service definition onto port 80, which the non-privileged user 1000 didn’t have perms for. Changing this to the default of 8080 worked. This is the working spec<\/a>. I’m slightly suspicious about the use of the environment variable for the volume but, as I say, it works.<\/p>\n","protected":false},"excerpt":{"rendered":" For ease of deployment, but without wanting to dive straight into Helm (just yet), I decided to try to stand up a very simple \/ crude Kubernetes deployment based on Jenkins. Needless to say, it wasn’t as simple as I’d … Continue reading