Im trying to run https://hub.docker.com/r/jhipster/jhipster/ as part of a Jenkins build on OpenShift, with CentOS host, but am getting the following error:
Failed to start container with docker id 38194274e387 with error:
Error response from daemon:
{"message":"invalid header field value \"oci runtime error: container_linux.go:247:
starting container process caused \\\"chdir to cwd (\\\\\\\"/home/jenkins/workspace/copy-of-sw\\\\\\\") set in config.json failed: no such file or directory\\\"\\n\""}
The dockerfile contents can be viewed on https://hub.docker.com/r/jhipster/jhipster/~/dockerfile/
Does anyone know how to resolve this?
For a Jenkins build, you want to use the CI image jhipster/jhipster-ci-stack https://hub.docker.com/r/jhipster/jhipster-ci-stack/
That Docker image jhipster/jhipster is used for developing with the generator, it will not work correctly in a Jenkins pipeline unless you are changing the generator and want to test that. How to use that image can be found in the "Docker installation (for advanced users only)" of https://jhipster.github.io/installation/
Related
I attempted to use sysbox-runc as the runtime for Docker on Ubuntu. sysbox-runc is operational. Nevertheless, an error occurred when I tried to create a container using Docker.
The command I was using: docker run --runtime=sysbox-runc nginx
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: container_linux.go:425: starting container process caused: process_linux.go:607: container init caused: process_linux.go:578: handleReqOp caused: rootfs_init_linux.go:366: failed to mkdirall /var/lib/sysbox/shiftfs/2e6d4302-28cd-4d9d-827e-6088b8b34e89/var/lib/kubelet: mkdir /var/lib/sysbox/shiftfs/2e6d4302-28cd-4d9d-827e-6088b8b34e89/var/lib/kubelet: value too large for defined data type caused: mkdir /var/lib/sysbox/shiftfs/2e6d4302-28cd-4d9d-827e-6088b8b34e89/var/lib/kubelet: value too large for defined data type: unknown.
ERRO[0000] error waiting for container: context canceled
Notes:
The same works fine with the default runtime runc.
Running docker and sysbox-runc as root.
Has anyone come across this before, please?
Is it ubuntu 22.04 ? Do you use kernel 5.15.(>=48) ? plz take a look at
Unfortunately there isn't much we can do with Ubuntu kernels 5.15.(>=48) as they are apparently missing a Ubuntu-patch on overlayfs that breaks interaction with shiftfs.
If you can, please upgrade to newer kernels (e.g., 5.19, 6.0, etc.).
If you must use kernel 5.15, try using 5.15.47 or earlier.
If you must use kernel 5.15.(>=48), you can work-around the problem by either:
Removing the shiftfs module from the kernel (e.g., rmmod) or
Configuring Sysbox to not use shiftfs. You do this by configuring the systemd service unit for sysbox-mgr, and passing the --disable-shiftfs flag to Sysbox. See here for more.
https://github.com/nestybox/sysbox/issues/596#issuecomment-1291235140
I have nearly the same problem as discussed here:
Docker build command with --tag unable to tag images
But I am not having an error occuring during build (as op figured out) but executing a server in the process. Last command of Dockerfile is a RUN command with a starting of a server. However, due to this, every-time I build this image, the build is never finished (it goes into the server-loop waiting for requests) and instead when stopping the container, an image with <none>:<none> was created.
is there any way to get this straight? Because the answer provided in the linked so-post just advises on changing the image name afterwards with a shell command.
I have two build servers building docker containers, a Windows10-1709 OS and Server2016-LTS, they both build containers based on microsoft/dotnet-framework:latest
These containers are then deployed by our CD system to a test Server2016-LTS host. The host is a VM and is restored to a checkpoint prior to each deployment. The checkpoint has the latest microsoft/dotnet-framework:latest image pulled and stored in it, checkpoint was updated today.
When the container from Server2016-LTS build server deploys, it just pulls our part of the image and is up and running in under 60 seconds.
When the image from the Windows10-1709 build server deploys, it takes ~10 minutes to deploy an image that contains ~10Mb of code. It's pull a different base image (I'm assuming one based on 1709). Once the pull completes, the image fails to run with the following error:
2018-02-15T23:15:57.3170769Z failed to register layer: re-exec error: exit status 1: output: time="2018-02-15T23:15:48Z" level=error msg="hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\\?\C:\ProgramData\docker\windowsfilter\d7defcca1ec427b77fca7528840e442a596598002140b30afb4b5bb52311c8c6 flavour=1 folder=C:\Windows\TEMP\hcs025707919"
2018-02-15T23:15:57.3171830Z hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\?\C:\ProgramData\docker\windowsfilter\d7defcca1ec427b77fca7528840e442a596598002140b30afb4b5bb52311c8c6 flavour=1 folder=C:\Windows\TEMP\hcs025707919
My assumption was that all the Microsoft/dotnet-framework:latest images are LTS, and you have to specify 1709 to get that base.
So why do my two docker images, which both have the same FROM in their docker file, behave so differently?
Thanks.
I am trying to install windowsServercore images on my WIndows 2016 server using below command.
Install-containerImage WindowsServerCore
while running it got below error message.
Install-ContainerOSImage : The term 'Install-ContainerOSImage' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Found there is a work around from article
https://social.msdn.microsoft.com/Forums/en-US/fc571caf-af13-45ed-a021-cfcfcf532645/the-term-installcontainerosimage-is-not-recognized-as-the-name-of-a-cmdlet-on-build-build-14385?forum=windowscontainers
While running the commands from the new article, getting different error message.
docker load -i nanoserver.tar.gz
58684737b3d1: Loading layer [==================================================>] 358.4 MB/358.4 MB
re-exec error: exit status 1: output: ProcessBaseLayer C:\ProgramData\docker\windowsfilter\dc41572502daedc9c628b56d1f369
ee804e901159b053d5e082e31e339ae822d: A required certificate is not within its validity period when verifying against the
current system clock or the timestamp in the signed file.
My system time is correct and i am running Windows 2016 server on AWS.
Any help to fix this issue is appreciated.
You can use bellow command to pull the image to your docker host which is windows server 2016:
docker pull microsoft/windowsservercore
Use the following command:
docker run -t -i mcr.microsoft.com/windows/nanoserver:1809
This will load Nano Server from the official Microsoft DockerHub repository:
https://hub.docker.com/_/microsoft-windows-nanoserver
I've been trying to set up an Continuous Delivery server with Bamboo. I've got everything going nicely up to the deployment. Bamboo builds and tests my C# project as it should.
Then I created a "deployment plan", installed docker and added the server capability to use docker, set up the docker tasks to build and deploy to dockerHub.
When I try to deploy, I get this error:
An error occurred trying to connect: Post http: //127.0.0.1:2375/v1.22/build ?buildargs=%7B%7D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&forcerm=1&memory=0&memswap=0&rm=1&shmsize=0&t=srgskiri%2Fresttest&ulimits=null : dial tcp 127.0.0.1:2375: connectex: No connection could be made because the target machine actively refused it.
01-mrt-2016 13:19:03 Failing task since return code of [C:\Program Files\Docker Toolbox\docker.exe build --force-rm=true --tag="srgskiri/resttest" C:\Users\Srg\bamboo-home\xml-data\build-dir\2129921-2195457] was 1 while expected 0
Now I think that it means that the bamboo 'object' that is calling the command to build, can't communicate with my docker engine/container.
First I thought it was because I didn't have docker-machine running, so I started it and ran the deploy, and still got this error.
This is what I have:
Server capability: path to docker
Docker task: building into an Image
Is there something I'm missing?
PS: Docker works perfectly on its own, both with docker UI or docker terminal. It's bamboo that can't interact with docker.
UPDATE: I didn't mention this, but I ran Bamboo in a Console, not as a service. Maybe thats the problem, that bamboo can't access docker out of console. I can't try this myself now because I can't install bamboo as a service. Keeps hanging if I try to start it as a service.
Will ask the bamboo support about it.
I figured it out... If u work on a Windows, Bamboo has to start the docker-machine itself.
So you have to add Command tasks to:
1) create a docker-machine (if u don't have any yet)
2) start it (if you start docker in bamboo, you can't access it in Windows and vice-versa)
only then you are able to use Docker in Bamboo on Windows.
I feel silly now
-EDIT- To use the Docker tasks after starting the docker-machine, you must also specify the Environment variables for the tasks (like DOCKER_TLS_VERIFY=1)
Otherwise you'll get the error mentioned above.