-1

I am currently new to Docker, I have been through a good amount of online tutorials and still haven't grasped the entire process. I understand that most of the tutorials have you pull from online public repositories.

But for my application I feel I need to create these images and implement them into containers from my local or SSH'd computer. So I guess my overall question is, How can I create an image and implement it into a container from nothing? I want to try it on something such as Python before I move onto my big project I will be doing in the future. My future project will be containerizing a weather research model.

I do not want someone to do it for me, I just have not had any luck searching for documentation, that I understand, that gives me a basis of how to do it without pulling from repositories online. Any links or documentation would be greatly received and appreciated.

twseewx
  • 302
  • 2
  • 11

1 Answers1

1

What I found confusing about Docker, and important to understand, was the difference between images and containers. Docker uses collections of files with your existing kernal to create systems within your existing system. Containers are collections of files that are updated as you run them. Images are saved copies of files that cannot be manipulated. There's more to it than that, based on what commands you can use on them, but you can learn that as you go.

First you should download an existing image that has the base files for an operating system. You can use docker search to look for one. I wanted a small operating system that was 32 bit. I decided to try Debian, so I used docker search debian32. Once you find an image, use docker pull to get it. I used docker pull hugodby/debian32 to get my base image.

Next you'll want to build a container using the image. You'll want to create a 'Dockerfile' that has all of your commands for creating the image. However, if you're not certain about what you want in the system, you can use the image that you downloaded to create a container, make the changes (while writing down what you've done), and then create your 'Dockerfile' with the commands that perform those tasks afterward.

If you create a 'Dockerfile', you would then move into the directory with the 'Dockerfile' and, to build the image, run the command: docker build -t TAG.

You can now create a container from the image and run it using:

docker run -it --name=CONTAINER_NAME TAG

CONTAINER_NAME is what you want to reference the container as and TAG was the tag from the image that you downloaded or the one that you previously assigned to the image created from the 'Dockerfile'.

Once you're inside the container you can install software and much of what you'd do with a regular Linux system.

Some additional commands that may be useful are:

CTRL-p CTRL-q # Exits the terminal of a running container without stopping it
docker --help # For a list of docker commands and options
docker COMMAND --help # For help with a specific docker command
docker ps -a # For a list of all containers (running or not)
docker ps # For a list of running containers
docker start CONTAINER_NAME # To start a container that isn't running
docker images # For a list of images
docker rmi TAG # To remove an image
Dave F
  • 1,837
  • 15
  • 20
  • Honestly, I wouldn't suggest installing software interactively. Far better to build it via a Dockerfile so it's part of an image, not a container. Containers are inherently transient. – Sobrique Feb 04 '16 at 21:02
  • So what if I download Redhat, and now I want to install my version of Python with a directory of scripts I have written, how would I implement that into the Redhat Environment that I pulled using docker pull "path to redhat". That's where I tend to get lost. – twseewx Feb 04 '16 at 21:22
  • @Sobrique When you build the Dockerfile, it runs the commands and saves it to an image. You can install everything interactively and then commit your changes to an image. The only difference that I can think of is that your log files might be longer due to mistakes being made. However, I suggested installing the software within the container for the sake of determining what commands should be used in the Dockerfile. – Dave F Feb 05 '16 at 02:18
  • @twseewx The RedHat image that you pull is the base set of files for your system, before everything else is installed. Let's say that you decide to use 'apollos/redhat6.5', you'd run `docker pull apollos/redhat6.5` to get the image. Then to create a container from it you can use `docker run -it --name=redhat_test apollos/redhat6.5`. You'll be in the shell for the container at this point. You can then run commands using 'yum' to install Python and whatever else you need. – Dave F Feb 05 '16 at 02:29
  • @twseewx After you've determined how to set up your environment, it would be good to create a Dockerfile that can replicate creating that environment. You can commit (save) your changes from the container to an image. However, creating the Dockerfile allows you to have a transcript of how to generate your system, it is small and easy to send to others, and it can easily be re-used to create your system if the image that your system is built on top of changes (or if you don't back that image up). – Dave F Feb 05 '16 at 02:36
  • @DaveF thanks for the explanations. this definitely has cleared up some of the confusion! I'm excited to get into it some more. – twseewx Feb 05 '16 at 03:44
  • If you "commit" an image, you need to rebuild it by hand to update it. If a new version of the software, bug fix, config change, whatever. Build it off a Dockerfile and this is a non issue. – Sobrique Feb 05 '16 at 05:45
  • @Sobrique What do you mean by 'rebuild [the image] by hand to update it'? I've read things like this many times, but the command `apt-get upgrade` upgrades my packages within the image. Is there some official documentation that says this? I understand doing this because of updates to Docker itself, because they may change how the program functions and existing containers or even images may become non-operational. – Dave F Feb 05 '16 at 12:22
  • @Sobrique I should be more clear. I store container data, such as web server files and files a database are stored in, via a volume. I don't see a good reason to use the Docker files to re-build a system when you're only performing regular upgrades. You can use `apt-get upgrade` and re-commit the image. If there's a problem with your container, where you need to re-build it, you can later use the Dockerfile to re-build the system. Using the Dockerfile to build a new image every time there are system updates wastes bandwidth and time re-downloading every single file. – Dave F Feb 05 '16 at 12:38
  • http://stackoverflow.com/questions/26110828/should-i-use-dockerfiles-or-image-commits – Sobrique Feb 05 '16 at 12:49
  • @Sobrique What follows from that is: update your system regularly and use a Dockerfile for a distribution upgrade. Yes, there are reasons why you should re-build your image, such as corrupt containers, distribution upgrades, etc. Assuming that all of the container files that get modified (perhaps outside of log files) are on an external volume and your Dockerfile is kept up to date, for regular updates, the only reason I can see for re-buliding with a Dockerfile is if security holes exist in the container format itself or updating using `apt` or `yum` doesn't properly update the system. – Dave F Feb 05 '16 at 13:51