I'm trying to get Jenkins up and running in Docker. I'm using the official repo and pulling the latest tag.
docker run -u 498 --name awsjenkins -p 8080:8080 -p 50000:50000 -v /mnt/jenkins:/var/jenkins_home jenkins
It starts okay, but it's throwing an error:
Apr 26, 2017 9:14:27 PM hudson.model.UpdateCenter updateDefaultSite
WARNING: Upgrading Jenkins. Failed to update the default Update Site 'default'. Plugin upgrades may fail.
java.io.IOException: Server returned HTTP response code: 503 for URL: http://updates.jenkins-ci.org/update-center.json?id=default&version=2.46.2
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
at hudson.model.DownloadService.loadJSON(DownloadService.java:172)
at hudson.model.UpdateSite.updateDirectlyNow(UpdateSite.java:190)
at hudson.model.UpdateCenter.updateDefaultSite(UpdateCenter.java:2197)
at jenkins.install.SetupWizard.init(SetupWizard.java:174)
at jenkins.install.InstallState$3.initializeState(InstallState.java:105)
at jenkins.model.Jenkins.setInstallState(Jenkins.java:1061)
at jenkins.install.InstallUtil.proceedToNextStateFrom(InstallUtil.java:96)
at jenkins.model.Jenkins.<init>(Jenkins.java:951)
at hudson.model.Hudson.<init>(Hudson.java:86)
at hudson.model.Hudson.<init>(Hudson.java:82)
at hudson.WebAppMain$3.run(WebAppMain.java:231)
A curl -L to that URL from the host machine returns a 301, so I don't think it's a firewall issue...
I am running this on Amazon, but I don't think that would cause any issues. I even opened up the security groups completely just for kicks, but I'm still getting this error. Also, I can access Jenkins. But when I do, it tells me that Jenkins is running offline.
Any thoughts on this?
Well, hopefully this helps someone else out... Thanks to Andy's comment, I was able to figure it out.
There's a few things going on here.
The official Dockerfile defaults to using 1000 for both the uid and gid. But really, 1000 is typically occupied by a candidate in the host OS. Personally, I think it should be changed to something a bit more obscure. Just my $.02...
When overriding the uid, it doesn't actually create the group. In Jenkins official documentation on Docker Hub, it says:
Ensure that /your/home is accessible by the jenkins user in container (jenkins user - uid 1000) or use -u some_other_user parameter with docker run.
The fix is pretty simple - pull the Dockerfile, modify it to work with your local user and uid/gid (there are several ways to do this), and build/run it.
Related
The Divio app shows an error when setting up the local Docker container because (according to 'divio doctor') DNS resolution inside Docker doesn't work.
I've setup an Ubuntu 18.1 VBox VM on a W10 host to serve as a Divio local development box. DNS resolution was never a problem when running Docker on the host though.
I added "dns": [8.8.8.8] to /etc/docker/daemon.json to get DNS to work from the terminal.
The following command returns the correct answer:
docker run busybox nslookup control.divio.com
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Name: control.divio.com
Address: 217.150.252.173
Anyone has an idea how to fix this?
What's happening is this: the command executed inside the container to test for DNS resolution (nslookup control.divio.com) has a 5 second timeout.
Your command (docker run busybox nslookup control.divio.com does just the same thing - but without the timeout.
For whatever reason, it's taking longer than 5 seconds to get a response, hence the failure in the first case.
It's not entirely clear why this sometimes happens, with no obvious reason - DNS resolution should not take so long.
You can disable this test though, by adding docker-server-dns to skip_doctor_checks in the ~/.aldryn file. See the Divio Cloud documentation for details.
Update 8th January 2019
The Divio App has been updated (to version 0.13.1) that you will be offered when you next launch it, along with the Divio CLI (to version 3.3.10) which if you use outside the Divio Shell can be installed with pip install --upgrade divio-cli.
In this update the way the lookup works has been changed to mitigate the effects of network problems when it does the DNS check (it now does a more restricted check).
You should now be able to re-enable the disabled docker-server-dns test in the ~/.aldryn file.
Update 8th March 2019
To complicate matters, it turns out that the Busybox image used to run these tests has changed in recent versions and it's quite difficult to ensure that the commands used in the test will work with whatever version of Busybox the user happens to have.
Running docker pull busybox will update the image, and for many users this has solved the issues. Some users will be able to reinstate the tests described above that would fail.
I'm new to Cassandra, and trying to get it going on OpenShift, 3.7 Origin.
I'm starting with a base image from DTR, cassandra:3. My Dockerfile is simply: FROM cassandra:3. During the oc new-app command my cassandra pod goes into a crash loop, the only log message that shows up is Running Cassandra as root user or group is not recommended - please start Cassandra using a different system user. If you really want to force running Cassandra as root, use -R command line option. I'm not able to run as root from OSE anyway, so I'm not trying to force it.
What doesn't make sense is the Dockerfile and deploy-entrypoint.sh don't appear to be running root. (And why would cassandra default to something it doesn't recommend?) I'm happy to extend the Dockerfile as needed to fix this error, but nothing I've tried has worked.
Does anyone know what I missed?
That image appears to expect to be started as root and then use gosu to change to the cassandra user, or be run with uid fixed to that matching the cassandra account created.
Under OpenShift with default security model, it will be forced to run as arbitrary user ID, which this image likely doesn't support.
If you have admin access, you could override security for the deployment to specify that it run as the uid for the cassandra account, then it may work.
I'm pulling my hair attempting to fix this error when installing GitLab CE through Helm on Kubernetes (helm install --namespace gitlab-ce --values gitlab-ce-values.yml --name gitlab-ce --set externalUrl=http://gitlab.local/ stable/gitlab-ce
Error executing action 'run' on resource 'ruby_block[directory resource: /gitlab-data/ssh]'
I have found one reply here with the following reply DJ Mountney:
one of your directories in /home/share/projects/repos is likely missing the execute bit for everyone. that means, that even though git owns /home/share/projects/repos it can't easily get there due to parent permissions.
You likely have to run a sudo chmod +x on /home/share (assuming that's the directory missing the execute flag)
This seemed to solve that person's issue, however, I have the correct flags set all the way from root, so this is not my issue.
I don't even know where to start. I've been at this for twelve hours and have gotten absolutely nowhere.
Can someone help me to proceed with installing GitLab on Docker (Kubernetes)?
UPDATE:I believe I've found a hint toward the issue. I was running Minikube through Virtualbox, which doesn't support advanced features on its mounted (shared) folders.
I have been trying to instead run minikube using xhyve, but now I can't access the Internet as Virtualbox has handled this previously. I'll keep at it.
I have used https://github.com/surajnarwade/opencompose-examples/tree/master/output-gitlab to get gitlab on kubernetes, I hope, that will help you.
I have been having a lot of problems pushing images with gcloud docker push over the past few weeks. I've read through the many stack overflow discussions and github issues and workarounds but I haven't come across a solution to the inconsistency yet.
Typically I will attempt to push a container image or two. The first push will almost always fail with the following retry-until-timeout output:
I can only get around it with gcloud auth login. At most 5 minutes later I will attempt to push a second image, and will again see the retry-until-timeout issue. I will see this on every attempt until I gcloud auth login again.
Often I will have to manually retry several more times immediately after authenticating before the image is actually pushed.
Am I actually being logged out (I can still access pods and instances, etc with kubectl and gcloud machines)? If so, why is being logged out inconsistent and what does building docker containers do that it would invalidate my local gcloud session?
If not, why can't I gcloud docker push until I authenticate again? After that, why is this still inconsistent (I suspect it may have little or nothing to do with the real issue).
Is there a way to make pushing images on OSX with docker-machine and gcloud docker push reliable? Is there another way to get images to the cloud repository (preferably from the command line)?
gcloud --version
alpha 2016.01.12
beta 2016.01.12
bq 2.0.18
bq-nix 2.0.18
core 2016.02.11
core-nix 2016.02.05
gcloud
gsutil 4.16
gsutil-nix 4.15
kubectl
kubectl-darwin-x86_64 1.1.7
docker --version
Docker version 1.10.1, build 9e83765
docker-machine --version
docker-machine version 0.6.0, build e27fb87
virtualbox version 5.0.14 r105127
I had the same or similar problem. After a few minutes of retry loop depicted with screenshoot above, the command will fail with net/http: TLS handshake timeout.
The solution that fixed it for me was editing the docker daemon configuration with
DOCKER_OPTS="--max-concurrent-uploads=1"
I had a feeling this issue was connected with docker clogging up the network, as I noticed even browsing to gmail can get a timeout(!)
Switching to regular docker push doesn't help timeouts. This appears to be related to your ISP and uploading assets.
I was receiving the same error. After moving the Docker build process to the cloud (which has a much larger pipeline), gcloud docker builds and deploys the image just fine.
I never faced the problems you mentioned with gcloud docker, but regarding your last point,
Is there another way to get images to the cloud repository (preferably from the command line)?
it is indeed possible to push to the gcr.io repos without going through gcloud, e.g:
docker login -e dummy#example.com -p $(gcloud auth print-access-token) -u _token https://gcr.io
docker push [your-image]
Credits to mattmoor, more info in original answer here:
Access google container registry without the gcloud client
I try to push my docker container to the google container registry, using this tutorial, but when I run
gcloud docker push b.gcr.io/my-bucket/image-name
I get the error :
The push refers to a repository [b.gcr.io/my-bucket/my-image] (len: 1)
Sending image list
Error: Status 403 trying to push repository my-bucket/my-image: "Access denied."
I couldn't find any more explanation (no -D, --debug, --verbose arguments were recognized), gcloud auth list and docker info tell me I'm connected to both services.
Anything I'm missing ?
You need to make sure the VM instance has enough access rights. You can set these at the time of creating the instance, or if you have already created the instance, you can also edit it (but first, you'll need to stop the instance). There are two ways to manage this access:
Option 1
Under the Identity and API access, select Allow full access to all Cloud APIs.
Option 2 (recommended)
Under the Identity and API access, select Set access for each API and then choose Read Write for Storage.
Note that you can also change these settings even after you have already created the instance. To do this, you'll first need to stop the instance, and then edit the configuration as mentioned above.
Use gsutil to check the ACL to make sure you have permission to write to the bucket:
$ gsutil acl get gs://<my-bucket>
You'll need to check which group the account you are using is in ('owners', 'editors', 'viewers' etc.)
EDIT: I have experienced a very similar problem to this myself recently and, as #lampis mentions in his post, it's because the correct permission scopes were not set when I created the VM I was trying to push the image from. Unfortunately there's currently no way of changing the scopes once a VM has been created, so you have to delete the VM (making sure the disks are set to auto-delete!) and recreate the VM with the correct scopes ('compute-rw', 'storage-rw' seems sufficient). It doesn't take long though ;-).
See the --scopes section here: https://cloud.google.com/sdk/gcloud/reference/compute/instances/create
I am seeing this but on an intermittent basis. e.g. I may get the error denied: Permission denied for "latest" from request "/v2/...."., but when trying again it will work.
Is anyone else experiencing this?
For me I forgot to prepend gcloud in the line (and I was wondering how docker would authenticate):
$ gcloud docker push <image>
In your terminal, run the code below
$ sudo docker login -u oauth2accesstoken -p "$(gcloud auth print-access-token)" https://[HOSTNAME]
Where
-[HOSTNAME] is your container registry location (it is either gcr.io, us.gcr.io, eu.gcr.io, or asia.gcr.io). Check your tagged images to be sure by running $ sudo docker images).
If this doesn't fix it, try reviewing the VM's access scopes.
If you are using Docker 1.7.0, there was a breaking change to how they handle authentication, which affects users who are using a mix of gcloud docker and docker login.
Be sure you are using the latest version of gcloud via: gcloud components update.
So far this seems to affect gcloud docker, docker-compose and other tools that were reading/writing the Docker auth file.
Hopefully this helps.
Same problem here, the troubleshooting section from https://cloud.google.com/tools/container-registry/#access_denied wasn't very helpful. I have Docker and GCloud full updated. Don't know what else to do.
BTW, I'm trying to push to "gcr.io".
Fixed. I was using a VM in compute engine as my development machine, and looks like I didn't give it enough rigths in Storage.
I had the same problem with access denied and I resolved it with creating new image using Tag:
docker tag IMAGE_WITH_ACCESS_DENIED gcr.io/my-project/my-new-image:test
After that I could PUSH It to Container registry:
gcloud docker -- push gcr.io/my-project/my-new-image:test
Today I also got this error inside Jenkins running on Google Kubernetes Engine when pushing the docker container. The reason was a node pool node version upgrade from 1.9.6-gke.1 to 1.9.7-gke.0 in gcp I did before. Worked again after the downgrade.
You need to login to gcloud from the machine you are:
gcloud auth login