I am trying to run nexus on EC2 ubuntu machine.
docker pull sonatype/nexus3
docker run -d -p 8081:8081 --name nexus sonatype/nexus3
running containers
# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a0562da202f7 sonatype/nexus3 "sh -c ${SONATYPE_DI…" 7 seconds ago **Exited (1) 5 seconds ago nexus**
#
Please do let me know what is going wrong here.
I tried to reproduce the problem and I face the same as you tried, I resolve this by setting these variables.
docker run -it --rm -p 8081:8081 --name nexus -e INSTALL4J_ADD_VM_PARAMS="-Xms2g -Xmx2g -XX:MaxDirectMemorySize=3g -Djava.util.prefs.userRoot=/some-other-dir" sonatype/nexus3
Also, you can read the system requirement
Notes
Our system requirements should be taken into account when provisioning the Docker container.
There is an environment variable that is being used to pass JVM arguments to the startup script
INSTALL4J_ADD_VM_PARAMS, passed to the Install4J startup script. Defaults to -Xms2703m -Xmx2703m -XX:MaxDirectMemorySize=2703m -Djava.util.prefs.userRoot=${NEXUS_DATA}/javaprefs.
Related
I created a new build for my Teamcity pipeline. For the first time I use then Docker buildstep. After I setup everything I realized the build agent does not seem to be ready for it.
I understand that my agent does not seem to be ready for building with docker but nobody is actually telling me how you can do that. I read the official guides but no word about how to actually install docker into my agent (if that's the way to solve the problem).
Can someone tell me what I have to do to get it to work?
EDIT
#Senior Pomidor helped me to get one step closer. I added his first example to the docker run command
docker run -it -e SERVER_URL="<url to TeamCity server>" \
--privileged -e DOCKER_IN_DOCKER=start \
jetbrains/teamcity-agent
After doing so I got rid of the mentioned messages in the screenshot. My Agents configuration now has the following:
docker.server.osType linux
docker.server.version 18.06.1
docker.version 18.06.1
But still Teamcity is complaining with this message:
Which kinda leaves me clueless again.
Final Solution:
The upcoming EDIT2 issue could be resolved by just restarting the teamcity server instance. The agent was actually able to run the build but teamcity was not able to realise that without a reboot.
EDIT2
Request Information:
My CI Server OS:
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
Running Container:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0f8e0b04d6a6 jetbrains/teamcity-agent "/run-services.sh" 19 hours ago Up 19 hours 9090/tcp teamcity-agent
20964c22b2d9 jetbrains/teamcity-server "/run-services.sh" 37 hours ago Up 37 hours 0.0.0.0:80->8111/tcp teamcity-server-instance
Container run by:
## Server
docker run -dit --name teamcity-server-instance -v /data/teamcity:/data/teamcity_server/datadir -v /var/log/teamcity:/opt/teamcity/logs -p 80:8111 jetbrains/teamcity-server
## Agent
docker run -itd --name teamcity-agent -e SERVER_URL="XXX.XXX.XXX.XXX:80" --privileged -e DOCKER_IN_DOCKER=start -v /etc/teamcity/agent/conf:/data/teamcity_agent/conf jetbrains/teamcity-agent
Build Step Information:
TC restricted the configuration because of TA doesn't start Docker daemon.
You should pass -e DOCKER_IN_DOCKER=start for automatically staring the docker daemon in the container. Also, docker daemon needs the docker socket. In a Linux container, if you need a Docker daemon available inside your builds, you have two options:
--privileged flag. New Docker daemon running within your container
-v docker_volumes:/var/lib/docker Docker from the host (in this case you will benefit from the caches shared between the host and all your containers but there is a security concern: your build may actually harm your host Docker, so use it at your own risk)
In a Linux container, if you need a Docker daemon available inside your builds, you have two options:
Docker from the host (in this case you will benefit from the caches shared between the host and all your containers but there is a security concern: your build may actually harm your host Docker, so use it at your own risk)
examples
docker run -it -e SERVER_URL="<url to TeamCity server>" \
--privileged -e DOCKER_IN_DOCKER=start \
jetbrains/teamcity-agent
docker run -it -e SERVER_URL="<url to TeamCity server>" \
-v /var/run/docker.sock:/var/run/docker.sock \
jetbrains/teamcity-agent
UPD
docker.server.osType required because in the build step was sets linux
What worked for me was changing permissions on the agent container for /var/run/docker.sock
Run a shell inside the container:
docker exec -u 0 -it <CONTAINER_ID> bash
Change permissions of the docker socket:
chmod 666 /var/run/docker.sock
Verify the docker container use the socket:
docker version
I have seen docker inside docker docker container for Ubuntu/Linux. As per the replies in this thread, the following command works
docker run -v /var/run/docker.sock:/run/docker.sock -v $(which docker):/bin/docker [your image
Are there any similar commands available for docker in Windows 7?
I am using the below command in Windows 10 to run docker inside docker. The docker image is with alpine OS. Note that the path is //var/run/docker.sock
docker run -it --rm --privileged --name dockerindocker -v //var/run/docker.sock:/var/run/docker.sock docker
/ # docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
02285c22006f docker "docker-entrypoint..." 3 seconds ago Up 2 seconds dockerindocker
/ # cat /etc/alpine-release
3.6.2
Unfortunately Windows doesn't support true docker-in-docker yet.
All the answers here are about running a docker client in a container which connects to the top level docker server on the host (same docker running the container where you invoke docker from). It is not a real docker in docker.
See discussion here for more details https://github.com/docker-library/docker/issues/49
I am trying to run the JHipster in docker container and followed the steps mentioned in https://jhipster.github.io/installation/.
> docker pull jhipster/jhipster
> mkdir ~/jhipster
> docker run --name jhipster -v ~/jhipster:/home/jhipster/app -v ~/.m2:/home/jhipster/.m2 -p 8080:8080 -p 9000:9000 -p 3001:3001 -i -t jhipster/jhipster
As I am running it in interactive mode it showing the JHIPSTER ASCII art and shows :: JHipster :: Running Spring Boot :: :: http://jhipster.github.io ::. Thats it.
When I docker ps:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f0015bd63658 jhipster/jhipster "tail -f /home/jhipst" 2 minutes ago Up 2 minutes 0.0.0.0:3001->3001/tcp, 0.0.0.0:8080->8080/tcp, 0.0.0.0:9000->9000/tcp jhipster
Now when I try to access localhost:8080 I am getting This page isn't working ERR_EMPTY_RESPONSE.
I checked in my ~/jhipster folder, there is nothing.
I logged into container with docker exec -it jhipster bash, there is nothing in app folder.
OS: MacOS
Docker Version: Docker version 1.12.5, build 7392c3b
docker-compose version 1.9.0, build 2585387
What am I missing?
When using the JHipster Docker image, all of the software requirements are installed but you still need to run the generator and choose your options.
Following along the installation documentation, you should log into the container, change to the app folder, and run jhipster:
docker container exec -it jhipster bash
cd /home/jhipster/app
jhipster
Once your application is created, you can run all the normal webpack/gulp and maven commands. For example, the following commands will start your backend and your frontend (run in separate terminals).
./mvnw
yarn start
Here is my CMD command in my Dockerfile for haproxy:
CMD ["/etc/init.d/haproxy"]
Now when I run the image the following happens:
...
Successfully built 2eb6549e0a22
root#server:/# docker run -d -p 80:80 -p 81:81 -p 443:443 -p 1988:1988 --name haproxy -h haproxy user/haproxy
09b510c4df712414d8855d3e0fb27b7e35d5c5c2f0f9b07f7f29c8efdb93e852
root#server:/# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
09b510c4df71 user/haproxy "/etc/init.d/haproxy" 5 seconds ago Exited (2) 4 seconds ago haproxy
As you can see it exits straight away. How do I keep it running?
Does your user/haproxy inherit from the haproxy container in the main docker repo? If so the command haproxy should be in the PATH and it includes a -f flag for running it in the foreground.
I usually specify the config file too, so my CMD looks like:
haproxy -d -f /usr/local/etc/haproxy/haproxy.cfg
I am running the example installation using docker container from the CKAN site. A clean run, that downloads fresh (no local images) gives no errors
docker run -d --name db ckan/postgresql
docker run -d --name solr ckan/solr
docker run -d -p 80:80 --link db:db --link solr:solr ckan/ckan
but then a "docker ps" does not have the ckan image running ...
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
90c6e6a77b0a ckan/solr:latest "java -jar start.jar 15 minutes ago Up 15 minutes 8983/tcp solr
53f9a9f5c145 ckan/postgresql:latest "/usr/local/bin/run" 20 minutes ago Up 20 minutes 5432/tcp db
Where would errors show?
docker ps only lists running containers. You have to pass in the -a option in order to list all containers you have run
docker ps -a
Find the right container and run the following command to see any error messages it may have reported before shutting down
docker logs <container_id>
As at March 6 2015 described at https://github.com/ckan/ckan/issues/2255
ensure that you have killed off any solr containers still running using
docker rm <idnumber>
then use the more recent schema config
wget https://github.com/ckan/ckan/blob/master/ckan/config/solr/schema.xml
docker run -d --name solr -v `pwd`/schema.xml:/opt/solr/example/solr/ckan/conf/schema.xml ckan/solr
then repeat the original failing step:
docker run -d -p 80:80 --link db:db --link solr:solr ckan/ckan
-- EDIT -- This looks like it works but it introduces other problems.
Am going to experiment with suggestion to use https://github.com/datacats/datacats