If you’re new to our Kubernetes 101 series, you can start by reading the first blog post, right here.
Intro
The usual way of developing an application is writing code locally, then deploying that code on a server.
Any differences between environments (permissions, database access, etc.) may lead to errors.
With containers, we can create a portable unit that contains all of the dependencies needed for it to run in any environment whether it’s local, development, testing, or production.
Microservices architecture for application development evolved out of this container development.
With containers, applications could be broken down into their smallest components, which could be developed and deployed independently instead of one monolithic unit.
Dockerfile
Now, moving forward to the nitty-gritty part of it.
Docker containers are created based on a Dockerfile.
A Dockerfile is a simple text file that contains a list of commands that the Docker client calls when creating an image.
Dockerfile basic commands
* FROM – specify base image
* COPY – copy files to the container
* RUN – install needed dependencies
* EXPOSE – the port number to be exposed
* CMD – the command to be run when the container starts
* ENTRYPOINT – the command to be run when the container starts
( CMD is used when a default command that can be easily overriden is needed, whereas ENTRYPOINT cannot be overriding )
Example:
FROM adoptopenjdk/openjdk11:alpine-jre // The base for the image – Alpine Linux
COPY /build/libs/application-0.1.jar application-0.1.jar // Copy the jar into the image
ENTRYPOINT [“java”,”-jar”,”application-0.1.jar”]. // The executable to start when the container is booting.
To create the container you need to run:
docker build . –tag=new-app // Creates the Docker image and adds it to the registry
docker run new-app // Creates and starts a container based on the Docker image
Follow the Kubernetes 101 series on mindit.io.
Check out new-spike.net for other articles on Kubernetes and much more!
