DEV Community: Zac Siegel

Using Docker for more on Apple Silicon

Zac Siegel — Thu, 07 Jan 2021 16:28:37 +0000

This article originated at zsiegel.com

Recently I have been using my new M1 Macbook Air as my primary development machine. This is in addition to my primary Intel based desktop machine and so when I started the ritual of installing my standard development tools I hit a bit of a snag.

Like many others I store all of my dotfiles in github. This helps me get up and running on a server or new computer quickly. I can then execute a simple script to install my tools via scripts - except Homebrew is not fully ready for the M1... and many of the tools I need are not ready either.

I read through Sam Soffes excellent post titled Homebrew on Apple Silicon and installed brew in a separate Rosetta terminal but I then took a step back to think about if this setup was really suiting my needs at this point. I was on a laptop with a small hard drive and I honestly did not want to have to install a ton of different development tools and all of their different versions to support my projects.

I stopped and asked myself - How could I setup my system such that I didnt need to install all these tools in the first place?

I knew Docker was the current standard for packaging and distributing tools and I used it daily for deploying code but could I leverage it more? Could I develop a system that would let me edit on my local machine but then run, debug, and test in containers?

Expert Docker Fu

In the past I had read about the crazy Docker fu from the likes of Jessie Frazelle where she runs chrome, spotify and skype in Docker with GUIs - but the commands to spin those up at the time when I read them felt a bit out of reach for me.

I had a feeling this might really be an ideal way to go about things and over my winter holiday break I ran across a great blog post from Jonathan Bergknoff titled Run More Stuff in Docker.

After reading Jonathans post and spending a little more time with the docker documentation I felt more confident in being able to achieve what I wanted.

Here is what I learned along the way as I attempted to set up all of my development projects to run with tools that only execute in Docker. Freeing me from installing any sofware via homebrew, letting me edit in my native app of choice, and even letting me easily opt-in to using arm64 compatible tools when available.

Mounting your current directory into a container

One of the most interesting bits from Jonathans blog post was how to mount your existing directory into the container and to set its working directory to that very same directory inside the container. The example below will take your current directory, mount it in your container of choice (in this case alpine), and set the working directory. This feels like magic. Its like taking your existing directory and dropping it right into the container with no changes.

docker run -it -v "$(pwd)":"$(pwd)" -w "$(pwd)" alpine:latest

Side note: On the M1 this launches almost instantly which is truly amazing.

Isolating tools and credentials

I am constantly switching between AWS, GCP and other cloud tools that have CLI clients with persistent configuration and credentials on my machine. I am always paranoid about running a command against the wrong environment and hate the thought of all my credentials being in some random directory managed by the tool itself.

Because of this I decided to create some shell aliases for each environments. They each have their own configuration directory that I specify for credentials. This means each container has only the tools and the specific credentials it needs.

An example of this utilizes a simple alpine container that has both Terraform and the Google Cloud CLI tools installed.

#!/usr/bin/env dockerfile-shebang
FROM alpine:3.8
ARG CLOUD_SDK_VERSION=321.0.0
ENV CLOUD_SDK_VERSION=$CLOUD_SDK_VERSION
ENV PATH /google-cloud-sdk/bin:$PATH

RUN apk add terraform=0.14.3-r0 --repository=http://dl-cdn.alpinelinux.org/alpine/edge/community

RUN apk --no-cache add \
        wget \
        python \
    && wget https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-${CLOUD_SDK_VERSION}-linux-x86_64.tar.gz && \
    tar xzf google-cloud-sdk-${CLOUD_SDK_VERSION}-linux-x86_64.tar.gz && \
    rm google-cloud-sdk-${CLOUD_SDK_VERSION}-linux-x86_64.tar.gz && \
    ln -s /lib /lib64 && \
    gcloud config set core/disable_usage_reporting true && \
    gcloud --version

I can then launch this container with a unique local config directory to isolate the credentials and mount them for use by the CLI tool. In this case im taking credentails from a local directory at /opt/local/gcloud/{PROJECT_ID}/{ENVIRONMENT} and mounting them at root/.config which is where the gcloud CLI tools expect the config to be.

Note that when I first start this container that might be empty! In this case because its a volume mapped to my local machine as soon as I run gcloud auth login those credentials will be saved from the container right into my local directory.

docker run -it -v "/opt/local/gcloud/{PROJECT_ID}/{ENVIRONMENT}":"root/.config" \
               -v "$(pwd)":"$(pwd)" \
               -w "$(pwd)" \
               zsiegel/devops:latest

Using Dockerfile-Shebang

If you read the Dockerfile above carefully above you will notice a shebang at the top of the Dockerfile. This is a bit odd at first but it allows you to make your dockerfiles executable so you can skip the build step which would be required if you need a custom image like in the example above.

This also makes it incredibly easy to setup a Dockerfile for each project and have it run fully isolated. No more pulling down a project and installing its dependecies on your local machine. It can all be isolated in a container!

Jake Wharton has created a script in homebrew to support this if thats your thing or you can just drop it right into your PATH.

With dockerfile-shebang installed I can now isolate any tools I need inside a dockerfile that is purpose built for that project.

For example I have a number of node projects for static websites. In each of my projects I have a filed called {PROJECT_NAME}.dockerfile at the root. The contents of the Dockerfile might look like the one below.

#!/usr/bin/env dockerfile-shebang
FROM amd64/node:lts-slim

With this file in the root of my project I can then run the following to have a fully isolated project environment that can be edited on my local machine in my editor of choice.


# Make the dockerfile executable first - do this only once
chmod +x zsiegel.com.dockerfile

# Run the environment
./zsiegel.com.dockerfile -it -p 8000:8000 -v "$(pwd)":"$(pwd)" -w "$(pwd)" -- /bin/sh

# In the container
yarn install
yarn dev

The command above is straight forward and builds upon what I learned in the earlier sections. I run my Dockerfile which is an executable thanks to the shebang package (note the dockerfile will be built automatically if needed), expose some ports so I can access it locally, then mount my current directory, set my work directory, and finally ask for a shell prompt.

Using AMD64 and ARM64

Before I mentioned that some tools are running on Apple Silicon and others are not. Another benefit I have found is the ability to opt-in to arm64 compiled tools where available. If you look below you will see examples of three Dockerfiles that specify different architectures.

Default Architecture - arm64 on Apple Silicon

#!/usr/bin/env dockerfile-shebang
FROM alpine:latest

 uname -sm
 Linux aarch64

This dockerfile without the architecture designation will detect your current machines architecture and try to use an appropriate container - in my case on Apple Silicon this will be an arm64 architecture.

x64 Architecture

#!/usr/bin/env dockerfile-shebang
FROM amd64/node:lts-slim

uname -sm
Linux x86_64

This dockerfile has the architecture designation so it will have the x64 architecture specified and run under emulation.

Tool Versioning

If you are a developer I am sure you know the pain of having to juggle multiple different versions of java, node, python, ruby and other tools. With the above tricks in hand I can now properly ensure all of my projects are isolated against the versions of software that they need.

If project X needs an older version of Go? I will setup a Dockerfile with the right version.
My new project Y can compile against the latest version of Java? Perfect its just another Dockerfile away.
I want to try out that new library but it requires some strange old version of something? No problem, just run it in a container!

2021 Docker and Me

The newfound knowledge above has allowed me to really streamline my workflow and minimize the tools I have to install and manage on this new M1 Macbook Air. I hope to continue to learn more about Docker and leverage it for running my development tools on my local machine.

A Developers Journey into Machine Learning: Installing Python, Jupyter, TensorFlow, and Keras

Zac Siegel — Fri, 31 May 2019 22:03:18 +0000

This article originated on zsiegel.com

Machine Learning as a developer

Machine learning is without a doubt one of the most interesting topics in computer science today. The breakneck pace and WOW factor associated with many machine learning demos has given it some mystique that still has me scratching my head wondering how it is even possible.

When I finally decided to jump in to machine learning I started with a list of questions that will undoubtedly take a very long time to eventuall answer but it at least gives me an initial direction.

Is a strong math and statistics background necessary?
Is there a set of basic terminology and concepts that will serve as a good foundation?
Is a high end GPU really necessary to do machine learning?
Are their types of machine learning that do not require a GPU?
Given the incredible pace of change are any of the books, tutorials and examples online from 1-2 years ago still relevant?

In order to explore these questions I set out to get up and running quickly so I could spend my time learning and experimenting. The following is what helped me get going rather quickly with minimal fuss.

Linux, Python, CUDA, TensorFlow, and Keras

I mentioned before that the breakneck pace of change in Machine Learning is staggering. I spoke to a number of colleagues that had dipped their toes into the space and one of the core challenges they faced was around the tooling.

Many of them had challenges keeping their toolchains and dependencies in simple working order. They were often experiencing minor version updates of various frameworks causing compatibility issues.

During my initial setup I experienced similar troubles so I slowly and systematically inched back to what appears to be a stable setup and has been reproduced across multiple machines.

PopOS 19.04
Python 3.7
TensorFlow 1.13.1
Keras 2.2.4
CUDA 10.0

Being a developer familiar with Docker I had to resist the urge to add yet another dependency to the tool chain so I instead looked through various Dockerfiles and found a combination that has worked across a number of projects and been rock solid on PopOS which is a linux distribution based on Ubuntu.

It all starts with some basic tools that can be isntalled via apt.

sudo apt install python3 python3-venv system76-cuda-10.0 system76-cudnn-10.0

It is important to note I chose PopOS for its developer repositories that made installing CUDA very simple.

If you are running a Debian based operating system and have NVIDIA display drivers installed you can get the System76 developer packages by doing the following.

sudo echo "deb http://apt.pop-os.org/proprietary bionic main" | sudo tee -a /etc/apt/sources.list.d/pop-proprietary.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key 204DD8AEC33A7AFF
sudo apt update

Setting up Python and Jupyter Notebooks

With the basic frameworks installed it was time to setup my development environment. As someone who develops primarily in strongly typed languages with a compiler I was not sure how I would fare living primarily in a python repl but I have found Jupyter to be incredibly flexible and enjoyable.

Jupyter notebooks are a wonderful way to explore and run examples both locally on your machine but also in the cloud. During my initial experiments I spent a ton of time browsing Jupyter notebooks on Github and playing around in Google Colab.

You can think of Jupyter notebooks as a combination of prose, documentation, runnable code, and console output.

At the moment I have decided to store all of my work in a single directory on my computer but I could see making dedicated environments as needed in the future.

I chose a single directory for everything because I can leave my jupyter server running and remotely access my Jupyter server from my iPad Pro using an app called Juno. This is something I will write about later in the future!

Now on to setting up Python and Jupyter.

# Create the directory where we will be storing everything
mkdir ~/src/jupyter
cd ~/src/jupyter

# Create a fully isolated python environment - this is similar to gradlew or other wrapper scripts you may have encountered in other languages
python3 -m venv jupyter-env

# This activates the virtual environment - when activated you will see your prompt change to indicate you are in `jupyter-env`. Any commands run after this will be scoped strictly to this environment
source jupyter-env/bin/activate

# Install the dependencies. Again its important to understand these dependencies are not globally available on your system. They are only available to the virtual environment we activated just before this
pip install pandas numpy tensorflow-gpu keras jupyter matplotlib pillow scikit-learn

# Store all of the dependencies into a text file. Make sure you run this command if you add any new dependencies using pip. You can use this file to re-install the dependencies on a new machine using `pip install -r requirements.txt`
pip freeze > requirements.txt

# Launch the notebook - this will start a jupyter server and open your web browser
jupyter notebook

With this setup I have been able to work on a number of learning exercises and the toolchain has not gotten in my way... at least not yet :).

Using Docker Machine to provision a remote docker host

Zac Siegel — Sat, 06 Apr 2019 22:43:18 +0000

This article originated on zsiegel.com

Like many developers my primary machine is a laptop and when developing applications I typically use Docker containers to provide local instances of databases, caches, message queues, and other supporting services.

When running these services via Docker this can often wreak havoc on my machine and cause it to slow down to a crawl even with lots of ram and CPU power. I began exploring options on how to get the ease and flexibility of Docker but use remote computing resources instead. I found that Docker has a great tool for enabling this type of workflow where the containers run on a different host but you can still access them just like they were on your machine.

Docker Machine

Docker has a built in tool called docker-machine that allows you to provision many different types of remote machines as docker hosts. In order for this to run all you need is a remote system that you have SSH access to. Docker can then provision that remote system and your local docker tools can interface with it instead of your local machine.

This allows you to run all sorts of heavier services on the remote machine instead of your local machine. Let’s take a look at how you might provision a simple docker host on a home server.

Docker Machine drivers

Take a look through the documentation and find what driver is appropriate for you. They provide many cloud drivers for running docker instances remotely. In this case we are going to provision a generic host on a ubuntu server running I have running in my home office.

I went ahead and installed Ubuntu 18.04 LTS and I have a basic root account setup. The first thing we need to do is enable SSH key authentication.

SSH Key Authentication

We are going to start by generating a set of keys to use for authentication with ssh-keygen. I named my keys zdocker since that is the hostname of the server I will be connecting to in my office.

Once these keys are generated you can utilize a tool called ssh-copy-id to automatically transfer the public key information to your server. In my case the command looked something like the following.

ssh-copy-id -i ~/.ssh/${PUBLIC_KEY} ${USERNAME}@${IP_ADDRESS}

You will want to replace the placeholders above with the public_key, username, and ip_address of your server in the command above. Once transferred you can now log into your server via public key authentication. I then went ahead and disabled password login via SSH since the only way we will allowing logins going forward is with the keys.

nano /etc/ssh/sshd_config

# Turn off PasswordAuthentication by setting the value to no 
# and making sure it is not commented out like below
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Now that we have SSH key authentication we need to enable password-less sudo privileges for the user that we intent to login with. This is required by the docker-machine installer.

Edit the sudoers file

sudo visudo

# Insert a new entry at the bottom that enables passwordless sudo
${USERNAME} ALL=(ALL) NOPASSWD: ALL

You will want to replace the username with the user that you have created on the machine.

Provision a Docker host

Now that we have SSH public key authentication setup with root access its time to let docker-machine provision our server.

docker-machine create \
    --driver generic \
    --generic-ip-address=$IP_ADDRESS \
    --generic-ssh-user $USERNAME \
    --generic-ssh-key ~/.ssh/$PRIVATE_KEY \
    zdocker

You will want to replace the placeholders above with the ip_address, username, private_key, and machine_name which in my example is zdocker.

Note that the machine_name will be what shows up in your CLI tool when you run docker-machine ls . It is how you will reference this remote docker instance when choosing which docker host to use for running your services.

If the provisioning was a success you will be greeted with some output similar to what is below.

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.1.10:2376"
export DOCKER_CERT_PATH="/path/to/a/cert"
export DOCKER_MACHINE_NAME="zdocker"
# Run this command to configure your shell: 
# eval $(docker-machine env zdocker)

Next run the eval command in your current shell to point your docker CLI at the remote host.

eval $(docker-machine env zdocker)

You now have docker pointed at a remote docker host. Within this shell all docker commands will utilize the remote system to do its work and your laptops hardware can breathe a little bit easier!

Java and Docker - JVM Runtime Basics

Zac Siegel — Thu, 13 Dec 2018 01:57:24 +0000

This article originated on zsiegel.com

As container deployments become increasingly common, it is important to understand how your application and runtime cooperate with various Linux container technologies.

Depending on your JVM target version, you may need to do a little extra work to ensure your Java runtime is aware of the processor and memory usage limits. If you are not careful, your application may have incorrect optimization or heuristics applied, potentially leading to performance issues and even crashes.

Namespaces and Cgroups

First, if you need to brush up on the underlying Linux technologies that make Docker possible, you might want to read Julia Evans excellent blog post here.

With a basic understanding of cgroups and namespaces we can now turn our attention to ensuring our Java runtime is aware of these technologies. Here is what you need to know in order to ensure your Java runtime is aware of the memory and processor limits set on your containers.

Java 7

Sadly there are no flags or features available in JDK 7 to provide container awareness. If you are running on JDK 7, you can tune your applications thread counts to reduce potential processor resource issues.

Java 8

Java 8 has a few flags that can help the runtime operate in a more container aware manner. These updates were added in the Java 8 Update 131 release which has been available since April 18, 2017.

The update contains improved processor and memory container awareness, and allows for use of experimental VM flags to enable automatic heap adjustment. To unlock this capability simply add the following flags to your java command line options.

java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -jar app.jar

These experimental flags set the heap size based on the value specified in the container’s sys/fs/cgroup/memory/memory.limit_in_bytes file. You can check out the bug report and work related to this here.

Java 9 & 10

Oracle has signaled that JDK 9 and JDK 10 will be automatically container aware respecting both processor and memory limits. They are also providing manual overrides to allow for disabling or setting these limits manually. There are a number of tickets and work on these features can be tracked on the OpenJDK Bug tracker which you can check out below.

Conclusion

There is still work to be done in order for the JVM to be fully aware of containerization, but so far excellent progress has been made and, more importantly, backported into JDK 8 in order to garner more feedback from the community.

If you find yourself running your Java application in containers and need help check back here frequently for more updates as I start a new series of articles on running java apps with Docker and Kubernetes.

Java and Docker - Memory and CPU Limits

Zac Siegel — Thu, 13 Dec 2018 01:54:17 +0000

This article originated on zsiegel.com

For many years java developers have gotten used to tweaking their code and the JVM flags to gain both performance and stability.

Now that we are deploying more often to containers its important to also understand how the underlying container technologies effect our application.

Let’s take a look at a real world example to understand how our application reacts when we adjust container flags that control memory and CPU allocation.

This example is applicable to Docker, Kubernetes, Mesos and other orchestrated container environments.

All of the following commands can be run on Docker CE for Linux and Mac v18 and up. We use JDK8 in these examples to demonstrate the lowest container aware JVM.

A Simple Executable

Let’s start off with a simple Java executable that logs to the console the processors detected and the max memory available to the runtime.

public class Docker {

  public static void main(String[] args) {

    Runtime runtime = Runtime.getRuntime();

    int processors = runtime.availableProcessors();
    long maxMemory = runtime.maxMemory();

    System.out.format("Number of processors: %d\n", processors);
    System.out.format("Max memory: %d bytes\n", maxMemory);
  }
}

We then create a simple Dockerfile that contains the JAR with this main function.

FROM openjdk:8-jre
COPY /build/libs/java-and-docker-1.0.jar java-and-docker.jar

CMD ["java", "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCGroupMemoryLimitForHeap", "-jar", "java-and-docker.jar"]

In this example, we are going to run JDK 8, which is the lowest container-aware JDK. For more information about the differences in container awareness capabilities between JDK versions, you can check out the previous article here.

Now we need to build the container.

$ docker build -t zsiegel:java-and-docker .

With the container built, let’s run this on the current machine and see what we get.

$ docker run zsiegel:java-and-docker
Number of processors: 4
Max memory: 466092032 bytes

You can compare this result to the CPU and memory settings in the Docker app preferences on the Mac or look at how it compares to your machine specs on Linux. The number of cores should match and the ram displayed should be slightly lower.

Memory Limits

Let’s take a look at limiting the memory the container can use and see how the runtime adjusts.

$ docker run -it --memory=512m zsiegel:java-and-docker
Number of processors: 4
Max memory: 119537664 bytes

Now that we have adjusted the amount of memory available to the container itself the heap size is adjusted by the runtime. How did the runtime decide on this value of 119537664 bytes which equates to roughly 120 megabytes? If you dig into the JVM Tuning guide you will see the following.

"Unless the initial and maximum heap sizes are specified on the command line, they're calculated based on the amount of memory on the machine. The default maximum heap size is one-fourth of the physical memory while the initial heap size is 1/64th of physical memory. The maximum amount of space allocated to the young generation is one third of the total heap size."

The runtime by default will use 1/4th of the available memory. In our case this means 512/4 = 128 megabytes which is roughly the number we see.

Processor Limits

Let’s take a look at limiting the cpu that is available to the container and see what happens. As of JDK 8 Update 131, the runtime should be aware of the number of cpus available and will tune thread counts accordingly. In the JVM's case one cpu is equal to one core.

$ docker run -it --cpus=1 zsiegel:java-and-docker
Number of processors: 4
Max memory: 468189184 bytes

This is not what I expected the first time I ran it so let’s dig in further to understand what is really going on.

The Docker --cpus flag specifies the percentage of available CPU resources a container can use. Specifically it refers to the cpu-shares. It does not adjust the number of physical processors the container has access to, which is what the jdk8 runtime currently uses when setting the number of processors.

There is future work to correct this shortcoming in JDK 10. You can follow the progress and discussion here

Let’s try using a different flag called --cpuset-cpus. This flag is used to limit the cores a container can use. On a 4 core machine we can specify 0-3. We can specify a single core or even multiple cores by comma separating the index of the cores.

$ docker run -it --cpuset-cpus=0 zsiegel:java-and-docker
Number of processors: 1
Max memory: 508887040 bytes

$ docker run -it --cpuset-cpus=0,1 zsiegel:java-and-docker
Number of processors: 2
Max memory: 508887040 bytes

This result is more in line with what we expected. We now have the runtime properly seeing 2 cores available instead of 4. When we do this the runtime will then tune the number of compiler and garbage collection threads accordingly.

It is important to note that many libraries and frameworks that rely on thread pools will tune the number of threads based on these numbers. You would think that this would address our problems but there is a catch!

Container Orchestration

There is a major problem with the above example. The vast majority of container orchestration tools like Mesos and Kubernetes set the cpu-shares and not the cpuset-cpus. This means that until the work in JDK10 mentioned earlier is completed the runtime and frameworks that rely on runtime.availableProcessors() will be unable to tune their thread count properly. My hope is that this work will be backported to at least JDK9 if possible.

If you want more info on the flags available in Docker for adjusting resource limits you can check out the documentation here

How to deploy Java apps in Docker

Zac Siegel — Thu, 13 Dec 2018 01:38:02 +0000

This article originated on zsiegel.com

Many java developers are familiar with deploying java applications via jar files and application containers such as Tomcat however many organizations are now deploying applications with Docker containers. Lets take a look at the bare minimum steps to get a java application running in a Docker container.

Install Docker

In order to run your java app in a container your are going to need Docker. Once installed Docker will allow you to build and run your containers on your local machine. It runs on many platforms including Linux, MacOS, and Windows. Head over to the Docker website and look for information on the supported platforms.

Once installed you can test out your installation by building and running the hello-world container. The output below indicates your installation was a success.

▲ :zsiegel (master)$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
d1725b59e92d: Pull complete 
Digest: sha256:0add3ace90ecb4adbf7777e9aacf18357296e799f81cabc9fde470971e499788
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Create a Dockerfile for your Java app

Now that you have Docker installed lets take a simple Java app built by Gradle and create a Dockerfile. We are going to both build and run the jar file within the container itself which gives us a more consistent environment. You can checkout my sample project on Github and work from this project if you would like.

Now that we have our basic Java app lets take a look at what a Dockerfile might look like.

# NOTE: This is not a production ready Dockerfile. 
# Utilize this only for development purposes

# Use a container image that has both Gradle and the JDK
FROM gradle:5.0.0-jdk8-alpine

# Switch to the `gradle` user defined by our container image
USER gradle

# Copy over the project directory into the container
COPY --chown=gradle:gradle . /java-and-docker

# Set our working directory to our project directory that we set above
WORKDIR /java-and-docker

# Run the build
RUN gradle build

# Run the jar file
# Since we are using JDK8 we set some additional flags to be more container aware
CMD ["java", "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCGroupMemoryLimitForHeap", "-jar", "build/libs/java-and-docker-1.0.jar"]

Build and Run your Java app in the Docker container

Now that we have our Dockerfile created we can ask docker to first build and then run our container with the following commands.

docker build -t zsiegel:java-and-docker .
docker run zsiegel:java-and-docker

Success

Now that you have successfully built and run a java app within a Docker container you can start exploring the related articles. These will help you understand how the java runtime and your apps will behave depending on the JVM version and the container flags you set. This is important because running java in a container is not as straightforward as it may seem.