I have been assigned the following task:
A Docker image with fresh Docker image (Ubuntu 14.04) or a PostgreSQL Docker image
User builds the image with "map.osm" in the parameters to 'docker build'.
I have completed the first part , but i am not sure what the second part really means.
I don't not quite understanding the 2nd part and how do i go about doing it ?
what does
User builds the image with "map.osm" in the parameters to 'docker
build'
mean ?? i have this file with me, but i am not quite sure how to builds the image with "map.osm" in the parameters to 'docker
build' , Can somebody explain what this means to me ? or even better show me an example ?
Thank you.
Alex-z.
Related
I have a debian package I am deploying that comes with a docker image. On upgrading the package, the prerm script stops and removes the docker image. As a fail safe, I have the preinst script do it as well to ensure the old image is removed before the installation of the new image. If there is no image, the following error reports to the screen: (for stop) No such image: <tag> and (for rmi): No such container: <tag>.
This really isn't a problem, as the errors are ignored by dpkg, but they are reported to the screen, and I get constant questions from the users is that error ok? Did the install fail? etc.
I cannot seem for find the correct set of docker commands to check if a container is running to stop it, and check to see if an image exists to remove it, so those errors are no longer generated. All I have is docker image tag to work with.
I think you could go one of two ways:
Knowing the image you could check whether there is any container based on that image. If yes, find out whether that container is running. If yes, stop it. If not running, remove the image. This would prevent error messages showing up but other messages regarding the container and image handling may be visible.
Redirect output of the docker commands in question, e.g. >/dev/null
you're not limited with docker-cli you know? you can always combine docker-cli commands with linux sh or dos commands as well and also you can write your own .sh scripts and if you don't want to see the errors you can either redirect them or store them to a file such as
to redirect: {operation} 2>/dev/null
to store : {operation} 2>>/var/log/xxx.log
I am taking a beginner course and not able to create an image on terminal.
Here is the course I am taking(Sorry, the course is in Japanese course but just for the reference). I am at 1:01:39 where he proceeds to create docker image.
First, the error message contained Failed to solve with frontend docker file.v0:failed to create LLB definition:the Dockerfile cannot be empty
I ran below command and managed to get rid of Failed to solve with frontend docker file.v0:failed to create LLB definition (Failed To Resolve With FrontEnd DockerFIle.v0):
export DOCKER_BUILDKIT=0
export COMPOSE_DOCKER_CLI_BUILD=0
Now I'm left with the Dockerfile cannot be empty
I saw in some page that people fail to locate because of not capitalized dockerfile but that's not my case.
I have also tried -f on the command to direct file
I saw that you, don't save your dockerfile, try save changes and run docker build again.
Also saw same issue on github, it could be helpful
Try to change COPY to ADD
https://github.com/docker/compose/issues/5170
I have a weird problem with Docker and hope someone here can help me :)
I want to create a keycloak image that is derived from the image jboss/keycloak. The idea is that in the Dockerfile also a preconfigured standalone.xml is copied into the image and keycloak can start directly without manual work.
But as soon as I write for example a
"CMD touch /opt/test.txt"
into the file the container crashes with the message "12:02:14,290 INFO [org.jboss.modules] (main) JBoss Modules version 1.9.1.Final
WFLYSRV0073: Invalid option '/bin/sh'"
This is just a new file with no purpose, the changes to the .xml are not in there yet.
As soon as I put only the FROM back in and rebuild everything works again.
I thought through the layers in the container you could mod an image, but here it doesn't seem to work. Can someone tell me why ?
So far it has always worked with the alpine image, but I don't want to build the whole keycloak setup again myself, when there is already an official image for it.
This is basically what I had in mind:
FROM jboss/keycloak:X.XX
CMD rm /opt/jboss/keycloak/standalone/configuration/standalone.xml
COPY ./keycloak/standalone.xml /opt/jboss/keycloak/standalone/configuration/
Thanks for help :)
Change
CMD rm
to
RUN rm
RUN is part of building. every RUN command is executed while your image is built.
With CMD you define (or override) the default command when running/starting a container based on your image (and you don't want to change keycloaks default CMD)
I have a testlink docker image running (named 'otechlabs/testlink').
Question 1: How do I get the original url from which I downloaded it (I can't remember) ? I would like to see the instructions about how to run the container.
It's running so fine that I saved a commit of it to run in another machine.
Question 2: Should I remember the run parameters(I can't remember)?
The container was created around 3 months ago.
Question 3: Instead of save/load, should I export/import?
Since I don't remember how to run the image, then I guess I should skip this step, perhaps (someway) copying the image to just start it in another host.
Q1:
You can try looking up the image in docker hub. The name otechlabs/testlink suggests that the user otechlabs in dockerhub has an image called testlink.
Now, I tried looking up the user's profile here but it appears that he doesn't have anything uploaded yet, maybe it is a private image.
If you're lucky you might be able to find something useful from other people's testlink image page.
Example:
https://hub.docker.com/r/rodrigodirk/testlink/
Q2:
Not quite sure what you meant here. Well if you have a running container of it, you can always do a docker inspect [CONTAINER_ID] to revisit the parameters used for starting it.
Example:
"Config": {
"ExposedPorts": {
"5432/tcp": {},
"9001/tcp": {}
},
"Env": [
"affinity:container==47eea8a078ad47583b4f5343302e7939a6d5f04ad929a079d8d9ae7cbee96d6a",
"POSTGRES_USER=bigCat01"
]
}
Q1: If you did a 'docker pull' the image id contains the url; if the id does not contain a domain name, then it is by default dockerhub repository
Q2: (as mentioned by Samual) if you still have a container saved run 'docker inspect ' to display the startup param's
Q3: if you modified the container you can 'commmit' the changes, and you can also change the tag: 'docker tag old_tag new_tag'
To help move it around, you could change he tag to gcr.io/project-id/new_tag:version and push it to google's container registry (free 30 day trail, may be free beyond that if you keep resource usage low) in your project 'project-id'
I was just going through this tutorail HERE about Docker images and to be more specific , it was about extending a docker image, now if you scroll to the section that says: Building an image from a Dockerfile , you'll see that a new Dockerfile is being built , now is this a independent image or is this Dockerfile extending the training/sinatra image ?? That would be by question.
So to repeat my question , is the Dockerfile in the Building an image from a Dockerfile section, creating a new image or extending the training/sinatra image ?
Thank you.
The command in that section is
docker build -t ouruser/sinatra:v2
That means it is creating a new image, extending the one mentioned in the Dockerfile: FROM ubuntu:14.04
The end result is:
a new image belonging to the user ouruser, the repository name sinatra and given it the tag v2.
each step creates a new container, runs the instruction inside that container and then commits that change - just like the docker commit work flow we saw earlier.
When all the instructions have executed we’re left with the 97feabe5d2ed image (also helpfully tagged as ouruser/sinatra:v2) and all intermediate containers will get removed to clean things up.
So again, this is an independent image, independent from training/sinatra.
To extends an image, you
either make a Dockerfile which starts "FROM <animage>", and build it: it will execute a series of docker commit on each intermediate containers.
or, and that is what is described in "Updating and committing an image", you do that manually, by running a bash, executing an order, exiting and committing the exited container into a new image.
The first approach scales better: you chain multiple commits specified in one Dockerfile.