I'm trying to run official image gitlab/gitlab-ce:latest by docker on my Windows 10.
First I tried to run it like below and it worked.
docker run --detach \
--hostname gitlab.example.com \
--publish 443:443 --publish 8080:80 --publish 22:22 \
--name gitlab \
--restart always \
--volume /srv/gitlab/config:/etc/gitlab \
--volume /srv/gitlab/logs:/var/log/gitlab \
--volume /srv/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest
But the problem was that changes in container were not saving. I found that the thing is in volumes. This attaching works only for Boot2Docker VM. Ok, I successfully shared my disk C:/ from host(Window) in docker settings(desktop application) and test it. Window's folder shared and I can see files in test container.
Now I'm trying ti run gitlab image like this:
docker run --detach \
--hostname gitlab.example.com \
--publish 443:443 --publish 8080:80 --publish 22:22 \
--name gitlab \
--restart always \
--volume C:\Users\Public\Gitlab\config:/etc/gitlab \
--volume C:\Users\Public\Gitlab\logs:/var/log/gitlab \
--volume C:\Users\Public\Gitlab\data:/var/opt/gitlab \
gitlab/gitlab-ce:latest
And got this error on container:
# Logfile created on 2017-06-21 16:33:44 +0000 by logger.rb/56438
[2017-06-21T16:33:45+00:00] INFO: Started chef-zero at chefzero://localhost:8889 with repository at /opt/gitlab/embedded
One version per cookbook
[2017-06-21T16:33:45+00:00] INFO: Forking chef instance to converge...
[2017-06-21T16:33:45+00:00] INFO: *** Chef 12.12.15 ***
[2017-06-21T16:33:45+00:00] INFO: Platform: x86_64-linux
[2017-06-21T16:33:45+00:00] INFO: Chef-client pid: 26
[2017-06-21T16:33:45+00:00] WARN: unable to detect ipaddress
[2017-06-21T16:33:46+00:00] INFO: HTTP Request Returned 404 Not Found: Object not found: chefzero://localhost:8889/nodes/9ca249ba6250
[2017-06-21T16:33:46+00:00] INFO: Setting the run_list to ["recipe[gitlab]"] from CLI options
[2017-06-21T16:33:46+00:00] INFO: Run List is [recipe[gitlab]]
[2017-06-21T16:33:46+00:00] INFO: Run List expands to [gitlab]
[2017-06-21T16:33:46+00:00] INFO: Starting Chef Run for 9ca249ba6250
[2017-06-21T16:33:46+00:00] INFO: Running start handlers
[2017-06-21T16:33:46+00:00] INFO: Start handlers complete.
[2017-06-21T16:33:46+00:00] INFO: HTTP Request Returned 404 Not Found: Object not found:
[2017-06-21T16:33:47+00:00] INFO: Loading cookbooks [gitlab#0.0.1, runit#0.14.2, package#0.0.0]
[2017-06-21T16:33:47+00:00] INFO: directory[/etc/gitlab] mode changed to 775
[2017-06-21T16:33:47+00:00] WARN: Skipped selecting an init system because it looks like we are running in a container
[2017-06-21T16:33:48+00:00] INFO: template[/var/opt/gitlab/.gitconfig] owner changed to 998
[2017-06-21T16:33:48+00:00] INFO: template[/var/opt/gitlab/.gitconfig] group changed to 998
[2017-06-21T16:33:48+00:00] INFO: template[/var/opt/gitlab/.gitconfig] mode changed to 644
[2017-06-21T16:33:48+00:00] INFO: Running queued delayed notifications before re-raising exception
[2017-06-21T16:33:48+00:00] ERROR: Running exception handlers
[2017-06-21T16:33:48+00:00] ERROR: Exception handlers complete
[2017-06-21T16:33:48+00:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/chef-stacktrace.out
[2017-06-21T16:33:48+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2017-06-21T16:33:48+00:00] ERROR: ruby_block[directory resource: /var/opt/gitlab/git-data] (gitlab::gitlab-shell line 26) had an error: Mixlib::ShellOut::ShellCommandFailed: Failed asserting that ownership of "/var/opt/gitlab/git-data" was git
---- Begin output of set -x && [ "$(stat --printf='%U' $(readlink -f /var/opt/gitlab/git-data))" = 'git' ] ----
STDOUT:
STDERR: + readlink -f /var/opt/gitlab/git-data
+ stat --printf=%U /var/opt/gitlab/git-data
+ [ root = git ]
---- End output of set -x && [ "$(stat --printf='%U' $(readlink -f /var/opt/gitlab/git-data))" = 'git' ] ----
Ran set -x && [ "$(stat --printf='%U' $(readlink -f /var/opt/gitlab/git-data))" = 'git' ] returned 1
[2017-06-21T16:33:48+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Please help, what did I do wrong?
I think I have a solution for running Gitlab from Docker on Windows 10; it appears to be working for me thus far.
For all of the Powershell, you'll need an elevated prompt.
Init
This first part gets the folders/volumes setup, then creates and starts the Gitlab container. (Remember that you have to have the Docker Desktop running and tell it to make the C drive shared.)
mkdir c:\GitlabConfig
mkdir c:\GitlabConfig\backups
docker volume create gitlab-logs
docker volume create gitlab-data
docker run --detach `
--name gitlab `
--restart always `
--hostname gitlab.local `
--publish 4443:443 --publish 4480:80 --publish 8222:22 `
--volume C:\GitlabConfig:/etc/gitlab `
--volume gitlab-logs:/var/log/gitlab `
--volume gitlab-data:/var/opt/gitlab `
gitlab/gitlab-ce
Wait a few minutes for Gitlab to finish initializing; just keep refreshing "localhost:4480/" in a browser until the web page comes up.
You can now use Gitlab however you were planning.
Backups
Edit the c:\GitlabConfig\gitlab.rb file. Find the 2 settings indicated, uncomment, and set them like so (this is what you'll end up with):
gitlab_rails['manage_backup_path'] = false
gitlab_rails['backup_path'] = "/etc/gitlab/backups"
Note that the "backups" folder is the same one created on the host back at the beginning, just how it's known inside the container.
Next, restart the container.
docker restart gitlab
Now you can backup Gitlab and it'll show up on the Windows host
docker exec -it gitlab gitlab-rake gitlab:backup:create
You will see a c:\GitlabConfig\backups\{prefix}_gitlab_backup.tar file in Windows after the process completes.
Restores
Once everything's ready for a restore, you can just run
gitlab gitlab-rake gitlab:backup:restore BACKUP={prefix}
Where {prefix} is everything that comes before the "_gitlab_backup.tar" of the filename you want to use for the restore. The restore functionality looks in the folder you configured earlier in the gitlab.rb file.
With this approach, I've been able to setup a running Gitlab container on Windows 10. I can just backup that main "c:\GitlabConfig" folder using any method I like.
Additionally, you can nuke the container and the 2 docker-volumes and start from scratch with just that folder's contents. If you start the new container by pointing it to your saved config folder, it'll have most of your stuff right out of the gate. But after it's done booting up, you can restore a backup and you'll be right back where you were. The docs presently indicate that there's problems with restoring when Gitlab is running in a container, but I didn't have any. If the restore runs into trouble, it should tell you what you need to fix before trying again
The hyperv filesharing mechanism does not support unix style file permissions. Because of this, the application encounters an error when it tries to assert that ownership is what it expects. I would guess that it tries to do a 'chown', followed by the following shell line that is described in your output:
[ "$(stat --printf='%U' $(readlink -f /var/opt/gitlab/git-data))" = 'git' ]
Error message indicates that it is expecting the owner to be 'git', but it gets 'root' instead.
You have two major possibilities. You could try to configure/change the process running inside your container to handle the situation. That might be as simple as changing the configuration so that it expects 'root' instead of 'git'. It may end up being much more involved than that. Your mileage may vary.
Your other option is to use a file system that does properly support unix style permissions and ownership. This would mean that you should switch to using a named volume, or switch back to using a host volume within the hyperv vm that Docker For Windows sets up. Either way, your files will reside in the VM instead of on your host's file system.
I would recommend using a named volume in this situation. Just keep in mind that if you reset your Docker For Windows VM, any data in a named volume will be reset as well.
Related
docker run -it --name mc3 dockerhub:5000/bitnami/minio-client
08:05:31.13
08:05:31.14 Welcome to the Bitnami minio-client container
08:05:31.14 Subscribe to project updates by watching https://github.com/bitnami/containers
08:05:31.14 Submit issues and feature requests at https://github.com/bitnami/containers/issues
08:05:31.15
08:05:31.15 INFO ==> ** Starting MinIO Client setup **
08:05:31.16 INFO ==> ** MinIO Client setup finished! ** mc: Configuration written to /.mc/config.json. Please update your access credentials.
mc: Successfully created /.mc/share.
mc: Initialized share uploads /.mc/share/uploads.json file.
mc: Initialized share downloads /.mc/share/downloads.json file.
**mc: /opt/bitnami/scripts/minio-client/run.sh is not a recognized command. Get help using --help flag.
dockerhub:5000/bitnami/minio-client - name of the image
It would be great if someone reach out to help me how to solve this issue as I'm stuck here for more than 2 days
MinIO has two components:
Server
Client
The Server runs continuously, as it should, so it can serve the data.
On the other hand the client, which you are trying to run, is used to perform operations on a running server. So its expected for it to run and then immediately exit as its not a daemon and its not meant to run forever.
What you want to do is to first launch the server container in background (using -d flag)
$ docker run -d --name minio-server \
--env MINIO_ROOT_USER="minio-root-user" \
--env MINIO_ROOT_PASSWORD="minio-root-password" \
minio/minio:latest
Then launch the client container to perform some operation, for example making/creating a bucket, which it will perform on the server and exit immidieatly after which it will clean up the client container (using -rm flag).
$ docker run --rm --name minio-client \
--env MINIO_SERVER_HOST="minio-server" \
--env MINIO_SERVER_ACCESS_KEY="minio-root-user" \
--env MINIO_SERVER_SECRET_KEY="minio-root-password" \
minio/mc \
mb minio/my-bucket
For more information please checkout the docs
Server: https://min.io/docs/minio/container/operations/installation.html
Client: https://min.io/docs/minio/linux/reference/minio-mc.html
I'm getting this error when executing docker run --rm -it alpine /bin/sh:
latest: Pulling from library/alpine
8921db27df28: Already exists
Digest: sha256:f271e74b17ced29b915d351685fd4644785c6d1559dd1f2d4189a5e851ef753a
Status: Downloaded newer image for alpine:latest
ERRO[0040] error waiting for container: context canceled
docker: Error response from daemon: Failed to inspect container 9919d1156d3960b46bca915bdf3b1d2320f463edbea5c39cacdc8b29640534fe: Error response from daemon: readlink /var/lib/docker/overlay2/l: invalid argument.
I'm using Docker Desktop on Windows with WSL 2.
I've tried docker rmi alpine:latest, but the error persisted.
I've tried docker system prune --all, but it didn't help.
Some of workarounds I've used:
When using the Docker command line, I specified a different version
of the image. Instead of alpine:latest, I used alpine:3.16, and it
helped.
I used Hyper-V instead of WSL 2 (Docker Desktop → Settings → General. Untick "Use the WSL 2 based engine")
As suggested in this answer, I reset Docker WSL 2 data. But
instead of resetting all Docker data, it is possible to clear only
WSL 2: Docker Desktop → Troubleshoot (it is the "bug" icon next to
the Settings icon) → Clean/Purge data, select WSL 2, and press Delete.
I able to run Flask API container successfully. But during the app execution it fails and stops the container for some reason.
I do checked container logs and noticed some file missing error is coming. Now I want to debug what file is missing by accessing /bin/bash of stopped container. But it throws an error saying container is not running.
docker exec -it CONTAINER /bin/bash
Is there any workaround to access bash in the STOPPED container?
No, you cannot.
However, it might be useful to either check the logs or specify bash as an entry point when doing a docker run
Checking logs: https://docs.docker.com/config/containers/logging/
docker logs <CONTAINER_NAME>
Shell Entry point: https://docs.docker.com/engine/reference/run/#entrypoint-default-command-to-execute-at-runtime
docker run --name <CONTAINER_NAME> --entrypoint /bin/bash <IMAGE_NAME>
If you container does not have /bin/bash, try
docker run --name <CONTAINER_NAME> --entrypoint /bin/sh <IMAGE_NAME>
You can try to use the docker commit command.
From the docs:
It can be useful to commit a container’s file changes or settings into
a new image. This allows you to debug a container by running an
interactive shell, or to export a working dataset to another server.
Resource with a example:
We can transform a container into a Docker image using the commit
command. All we need to know is the name or the identifier of the
stopped container. (You can get a list of all stopped containers with
docker ps -a).
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
0dfd54557799 ubuntu "/bin/bash" 25 seconds ago Exited (1) 4 seconds ago peaceful_feynman
Having the identifier 0dfd54557799 of the stopped container, we can
create a new Docker image. The resulting image will have the same
state as the previously stopped container. At this point, we use
docker run and overwrite the original entrypoint to get a way into the
container.
# Commit the stopped image
docker commit 0dfd54557799 debug/ubuntu
# now we have a new image
docker images list
REPOSITORY TAG IMAGE ID CREATED SIZE
debug/ubuntu <none> cc9db32dcc2d 2 seconds ago 64.3MB
# create a new container from the "broken" image
docker run -it --rm --entrypoint sh debug/ubuntu
# inside of the container we can inspect - for example, the file system
$ ls /app
App.dll
App.pdb
App.deps.json
# CTRL+D to exit the container
# delete the container and the image
docker image rm debug/ubuntu
You can't because this container is dead as well as turned down virtual machine is dead. You can check logs using docker logs command.
docker container ls -aq
docker logs <name_of_your_dead_container>
From the man pages from docker-run:
--entrypoint=""
Overwrite the default ENTRYPOINT of the image
So use something like:
docker run --entrypoint=/usr/bin/sleep 1000 ......
This will start the container and wait 1000 seconds, allowing you to connect and debug.
I'm using Minikube in Windows 10 and I'd like to use locally built Docker images instead of images hosted in a registry, so, according this tutorial, I have to run next commands:
Use local kubernetes and images:
> minikube docker-env
The output is:
PS C:\WINDOWS\system32> minikube docker-env
$Env:DOCKER_TLS_VERIFY = "1"
$Env:DOCKER_HOST = "tcp://10.98.38.126:2376"
$Env:DOCKER_CERT_PATH = "C:\Users\MyUser\.minikube\certs"
# Run this command to configure your shell:
# & minikube docker-env | Invoke-Expression
To configure the shell, run this:
> & minikube docker-env | Invoke-Expression
After that, I need to build a new image:
PS D:\repos\test> docker build -t miImage:v1 .
And I have next error:
PS D:\repos\test> docker build -t miImage:v1 .
Sending build context to Docker daemon 8.62MB
Step 1/10 : FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS build-env
Get https://mcr.microsoft.com/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
This is error is thrown since I configured it to use local images, is there any way to fix it?
it looks like the machine that you're using to build is unable to reach https://mcr.microsoft.com/v2/ to confirm that, try to send a simple GET to the URL
wget https://mcr.microsoft.com/v2/
if that's the problem, you can use a different machine to pull the image, then save it to a file and load it on the target machine.
#on a machine connected to internet
docker pull mcr.microsoft.com/dotnet/core/sdk:2.2
docker save mcr.microsoft.com/dotnet/core/sdk:2.2 > dotnetsdk2_2.tar
# download the file
# on the target machine
docker load < dotnetsdk2_2.tar
then your build should work without a problem using the local version of the image.
My goal is to be able to remote debug from Atom.io. into a docker container running go in dlv debugger. This is the first problem:
Update:1. I am running Docker container on a mac, but that should not influence the code signing thing as I am running in a container, right?
Update:2. Codesignig the host, did not help.
Error:
1. root#...:/go/src/app# go get github.com/derekparker/delve/cmd/dlv
2. root#...:/go/src/app# dlv debug hello.go
could not launch process: fork/exec ./debug: operation not permitted
Then tried to
1. root#...:/go/src/app# sudo
2. bash: sudo: command not found
According Delve Issue #515
Docker has security settings preventing ptrace(2) operations by
default with in the container. Pass --security-opt seccomp:unconfined
to docker run when starting.
*confirmation of this in official docker bug tracker https://github.com/docker/docker/issues/21051
It seems to work if you start the container with --privileged. I've tried to figure out if there is a more fine-grained capability but failed.
Also I just found https://github.com/steeve/homebrew-delve which should make things easier on OSX.
Docker has security settings preventing ptrace(2)
See how i fixed it.
if using a docker-compose file to run the container then append seccomp:unconfined in the services section like below
api:
security_opt:
- seccomp:unconfined
if using docker run ...passing seccomp:unconfined works as well
Run Docker container as a command:
docker run -itd -p 2028:22 -p 2345:2345 --dns=10.236.8.8 --privileged=true --name=golang centos7-golang /usr/bin/supervisord
it works for me~