Docker Desktop allows us to work on Windows images and Linux, but sadly (at least at the moment) we may need to switch the builder used by it, either by using the UI or
DockerCli -SwitchDaemon
DockerCli -SwitchLinuxEngine
DockerCli -SwitchWindowsEngine
You’ve created you React application and are now looking to create a docker image for it.
Before we look at the Dockerfile, create yourself a .dockerignore file that looks like this
.git node_modules
We do not require the .git folder in our image and we’re going to install our node modules via npm install as you’ll find copying the node_modules folder(s) is slow.
Let’s jump straight in and look at a Dockerfile that will take our React code containerize it and set the container up to run nginx to host it.
FROM node:21-alpine3.18 as build WORKDIR /usr/app COPY . . RUN npm install RUN npm run build FROM nginx:alpine COPY --from=build /usr/app/build /usr/share/nginx/html EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]
We’re using a node alpine image as our base. This is a lightweight image as we won’t our image to be lean. Next we create our WORKDIR, this can be set to your preferred location but just remember to reuse that location in the COPY command. We’re using .dockerignore to ignore .git and node_modules which allows us to then just copy everything to the image, where we then install then build our React application.
Finally we use nginx to serve our application, first copying the build folder to nginx and finally we set up the CMD to run nginx once the container is started, thus hosting our React application.
To build our image we can just use the following (change the tag name and version to suit your application)
docker build -t my-app:0.1.0 .
and to run, again set your application name any port redirects and use you tagged and version
docker run --rm --name my-app -p 8080:80 -d my-app:0.1.0
We could also extend this sample to include copying of nginx.conf to the image, for example if you want the supply a config like this
worker_processes 4;
events { worker_connections 1024; }
http {
server {
listen 4200;
root /usr/share/nginx/html;
include /etc/nginx/mime.types;
location / {
root /usr/share/nginx/html;
index index.html;
try_files $uri $uri/ /index.html;
}
}
}
If we assume we’re storing out nginx.conf file in a folder named .ngnix (this is not required it’s just for this example) then we could add the following to the Dockerfile, after the line FROM nginx:alpine add the following and whilst we’re at it let’s get rid of the default files that might be located in the images nginx/html folder
COPY ./.nginx/nginx.conf /etc/nginx/nginx.conf RUN rm -rf /usr/share/nginx/html/*
Docker Compose
Whilst we’re here, let’s create a simple docker-compose.yaml file for our new image.
version: '3.8'
services:
front-end:
build:
context: ./ui
dockerfile: ./ui/Dockerfile
ports:
- 4200:4200
image: putridparrot/my-app:0.1.0
container_name: my-app
We might like to store configuration for this image on the hosting server, i.e. via a volume in which case we’d simply add to the bottom of this file the following
volumes:
- ./ui/public/appsettings.json:/usr/share/nginx/html/appsettings.json
In this example we’re using an appsettings.json file to configure the environment, or it might include feature flag settings or whatever and assuming it’s stored in the public folder of you React application.
Now we just docker-compose up.
Note: I’m going through draft posts that go back to 2014 and publishing where they still may have value. They may not be 100% upto date but better published late than never.
Up until recently I’ve been solely using Docker on Linux, but I’ve a need to use it with Windows now. I’ve installed Docker Desktop and set to Switch to Windows containers.
So first off we’re going to download a Windows image, whilst there are several variants, for server, nano windows, we’re going to go pretty much full blown using
docker pull mcr.microsoft.com/windows:2004
Note: It may take some time to download, it’s > 3GB
Now just to prove it worked let’s run it in interactive mode and starting the cmd prompt using
docker run -it mcr.microsoft.com/windows:2004 cmd.exe
Exit your image by typing exit followed by return.
I’m going to want to create a volume to save/share files with the Windows machine running the container, so let’s create a folder c:\shared and then copy or create a file in here, just to allow us to prove we can connect to it through the container, so mine’s predictably HelloWorld.txt, now run
docker run -it -v c:\shared:c:\shared mcr.microsoft.com/windows:2004 cmd.exe
Note: Change cmd.exe to powershell.exe if you prefer
I’m naming the folder in the image the same as the real machine’s folder, but you can change it to suit, just change the second path like this
docker run -it -v c:\shared:c:\shared2 mcr.microsoft.com/windows:2004 cmd.exe
and if you created a simple text file with a message in it, once we’re inside the container we can type
type HelloWorld.txt
from the c:\shared folder to see it it’s as expected.
Now I’m wanting to start to install applications into the container, but with no GUI we need “silent installs”
msiexec /i .\myapp.msi /QN /L*V install.log
Let’s run up the Docker image with an instance of PostgreSQL
docker run --name mypostgres -d postgres
Now, connect to the instance so we can create a database etc.
docker exec -it mypostgres bash
createdb -U postgres MyDatabase
Note: if you find this error message psql: FATAL: role “root” does not exist, you’ll need to switch to the postgres user, see below.
Switch to the postgres user (su substitute user).
su postgres psql
At which point, we’re now in the psql application and can create databases etc.
I’ve actually covered this in a previous post, but because it was part of Eureka Server (using Steeltoe) revisited. It didn’t quite stand out when I was searching for it, so let’s recreate here in it’s own post…
Pull the docker image using
docker pull steeltoeoss/eureka-server
Now to run it
docker run --publish 8761:8761 steeltoeoss/eureka-server
This will now be available locally or remotely on port 8761, i.e.
http://locahost:8761
In the previous post we looked and an “off the shelf” image of nginx, which we deployed to Kubernetes and were able to access externally using Ingress. This post follows on from that one, so do refer back to it if you have any issues with the following configurations etc.
Let’s look at the steps for deploying our own Docker image to k8s and better still let’s deploy a dotnet core webapp.
Note: Kubernetes is deprecating its support for Docker, however this does not mean we cannot deployed docker images, just that we need to use the docker shim or generated container-d (or other container) images.
The App
We’ll create a standard dotnet ASP.NET core Razor application which you can obviously do what you wish to, but we’ll take the default implementation and turn this into a docker image and then deploy it to k8s.
So to start with…
dotnet new webapp -o razordemo --no-https -f net5.0
It’d be good to see this is all working, so if let’s run the demo using
dotnet run
Now use your browser to access http://your-server-ip:5000/ and you should see the Razor demo home page, or use curl to see if you get valid HTML returned, i.e.
curl http://your-server-ip:5000
Generating the Docker image
Note: If you changed launchSettings.json to use 0.0.0.0, reset this to localhost.
Here’s the Dockerfile for building an image, it’s basically going to publish a release build of our Razor application then set up the image to run the razordemo.dll via dotnet from a Docker instance.
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build WORKDIR /src COPY razordemo.csproj . RUN dotnet restore COPY . . RUN dotnet publish -c release -o /app FROM mcr.microsoft.com/dotnet/aspnet:5.0 WORKDIR /app COPY --from=build /app . ENTRYPOINT ["dotnet", "razordemo.dll"]
Now run docker build using the following
docker build . -t razordemo --no-cache
If you want to check the image works as expect then run the following
docker run -d -p 5000:80 razordemo
Now check the image is running okay by using curl as we did previously. If all worked you should see the Razor demo home page again, but now we’re seeing if within the docker instance.
Docker in the local registry
Next up, we want to deploy this docker image to k8s.
k8s will try to get an image from a remote registry and we don’t want to deploy this image outside of our network, so we need to rebuild the image, slightly differently using
docker build . -t localhost:32000/razordemo --no-cache
Reference: see Using the built-in registry for more information on the built-in registry.
Before going any further, I’m using Ubuntu and micro8s, so will need to enable the local registry using
microk8s enable registry
I can’t recall if this is required, but I also enabled k8s DNS using
microk8s.enable dns
Find the image ID for our generated image using
docker images
Now use the following commands, where {the image id} was the one found from the above command
docker tag {the image id} localhost:32000/razordemo
docker push localhost:32000/razordemo
The configuration
This is a configuration based upon my previous post (the file is named razordemo.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
selector:
matchLabels:
run: webapp
replicas: 1
template:
metadata:
labels:
run: webapp
spec:
containers:
- name: webapp
image: localhost:32000/razordemo
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: webapp
labels:
run: webapp
spec:
ports:
- port: 80
protocol: TCP
selector:
run: webapp
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: razor-ingress
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: webapp
port:
number: 80
Now apply this configuration to k8s using (don’t forget to change the file name to whatever you named your file)
kubectl apply -f ./razordemo.yaml
Now we should be able to check the deployed image, by either using the k8s dashboard or run
kubectl get ep webapp
Note the endpoint and curl to that endpoint, if all worked well you should be able to see the ASP.NET generate home page HTML and better still access http://your-server-ip from another machine and see the webpage.
The Eureka server is used as a registry for maintaining lists of services and their endpoints. It’s used a lot in the microservice world by way of a microservice registering it’s existence somewhere (in this case in Eureka). When a client (whether it’s another service or anything else for that matter) want to access a service it asks the registry for an instance, in this case we connect to the Eureka server and find the services instance(s) that are available for a specific application name and are ofcourse UP.
Installing and running Eureka Server
In a previous post Spring boot Eureka server we wrote a Java application to run a Eureka server. In this post we’re going to use Docker to host the server and then use Steeltoe with .NET to interact with the instance.
To get an image of Eureka server, let’s use the Steeltoe docker image (Spring and others exist, the Steeltoe image is not intended for production, but is fine for what we want to do)
docker pull steeltoeoss/eureka-server
Now run up the docker image using
docker run --publish 8761:8761 steeltoeoss/eureka-server
If all goes well, connect to the Spring Eureka dashboard using
http://locahost:8761
change localhost to the ip/host you’re running the Eureka server from, now you should now see the Spring Eureka web page.
Registering a .NET core client with Eureka
I’ve a post on this topic A .NET service registered with Eureka, but let’s go through the process again with the current version of Steeltoe (as the NuGet packages have changed somewhat).
services.AddDiscoveryClient(Configuration);
app.UseDiscoveryClient();
// Eureka info
"eureka": {
"client": {
"serviceUrl": "http://localhost:8761/eureka/",
"shouldFetchRegistry": "false",
"shouldRegisterWithEureka": true,
"validateCertificates": false
},
"instance": {
"appName": "weatherapi",
"port": "8080",
"ipAddress": "localhost",
"preferIpAddress": true
}
}
We’re going to leave the API with the default weatherapi, hence the appName in the appsettings.
Notice we set the value for “shouldFetchRegistry” to false as this service will not be acting as a client to any other services. Obviously change this is you also need to discovery other services. “shouldRegisterWithEureka” is set to true as we want this service to automatically register itself with Eureka.
Now navigate to the URL of your Eureka server again (or refresh) and you should see a new Application. In my case I have an application with the name weatherapi. This name comes from our appsettings.json configuration application/name.
Info and Health
If you click on the instance link within the Eureka server dashboard, you will navigate to
https://localhost:5001/info
(or whatever ip/hostname and port your service is running on) you get a 404, so let’s fix that in our project.
Info, by default will display some basic information about the application, product version etc. However you can also add further custom information if you want, but example the git build SHA1 hash or just some general info.
services.AddSingleton<IInfoContributor, MyInfoContributor>(); services.AddInfoActuator(Configuration); services.AddHealthActuator(Configuration);
The first of these lines will add our implementation of an IInfoContributor to allow for custom info.
endpoints.Map<InfoEndpoint>(); endpoints.Map<HealthEndpoint>();
public class MyInfoContributor : IInfoContributor
{
public void Contribute(IInfoBuilder builder)
{
builder.WithInfo("MyInfo", new { SomeName = "Scooby Doo" });
}
}
Now when we run our service we hope to see our info data, however by default Steeltoe seems to set the info and health endpoint to /actuator/info and /actuator/health respectively. Eureka seems to expect /info. So go to the appsettings.json and add the following to the Instance section
"StatusPageUrlPath": "/actuator/info", "HealthCheckUrlPath": "/actuator/health"
Note: I’m not sure what I’m missing here and why the defaults don’t match up, but these configuration changes will tell the Eureka server (when we register our service with it) that it should use these paths for info and health.
Now, if you run the service again for /actuator/info you should see something like this
{"MyInfo":{"someName":"Scooby Doo"},
"applicationVersionInfo":{"ProductName":"RegisterExample",
"FileVersion":"1.0.0.0","ProductVersion":"1.0.0"},
"steeltoeVersionInfo":"ProductName":"Steeltoe.Management.Endpoint",
"FileVersion":"3.0.2.0","ProductVersion":
"3.0.2\u002B4089779c66d127f40325a3be9b613149b3b090f2"}}
and health something like
{"status":"UP","details":{"liveness":{},"diskSpace":{"total":4000769372160,
"free":3889734168576,"threshold":10485760,"status":"UP"},"eurekaServer":
{"remoteInstStatus":"UNKNOWN","fetchStatus":"Not fetching","heartbeat":
"Successful","heartbeatStatus":"UP","heartbeatTime":"2021-01-23T20:40:44",
"status":"UP","applications":"NONE"},"readiness":{}}}
I wanted to get a Blazor server application up and running on Ubuntu within a docker container (I’m running the whole thing on a Raspberry Pi 4 with Ubuntu Server).
The first stage for this post will simply be about creating a Dockerfile and creating a Blazor server application via the dotnet template.
We’re going to want the latest version of dotnet core, so let’s start by creating a very bare bones Dockerfile which will create an image based upon
mcr.microsoft.com/dotnet/core/sdk:3.1, it will also expose the standard HTTP port used in the Blazor server template, i.e. port 5000
Here’s the Dockerfile
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 ENV APP_HOME /home RUN mkdir -p $APP_HOME WORKDIR $APP_HOME EXPOSE 5000 CMD [ "bash" ]
To build this image run the following
docker rmi dotnet-env --force docker build -t dotnet-env .
The first line is solely there to remove any existing image (which will be especially useful whilst developing the image). The second line will build the Dockerfile and name it dotnet-env.
Once built, let’s run the image to see all is good with it. So simply run
docker run -it --rm -p 5000:5000 -v /home/share:/home/share dotnet-env
In this example we’ll run docker in interactive mode and map ports using -p to map the host port 5000 to the exposed port in the image. We’ll also also created a volume link from the container to the host.
Once we’ve run the image up we should be placed into a BASH command prompt, now we can simply run
dotnet new blazorserver -o MyServer
To create the project MyServer, once created cd into the MyServer folder. Now run
dotnet run
A kestrel server should start up, and you might be able to access the server using http://server-ip-address. I say might, because you may well see an error at startup, saying something like
Unable to bind to http://localhost:5000 on the IPv6 loopback interface: ‘Cannot assign requested address’.
What you need to do is go into the Properties folder and open launchSettings.json, change the line
"applicationUrl": "https://localhost:5001;http://localhost:5000",
to
"applicationUrl": "http://0.0.0.0:5001;http://0.0.0.0:5000",
Next Step
This obvious next step to our docker build is to create a Docker image which contains our application and runs it when the container is started. We’re going to build and publish the using dotnet publish -c Release -o publish and then include the published files in our docker container, alternatively you might prefer to have the Dockerfile build and publish the project as part of its build process.
For now let’s just build our Blazor server application, then publish it to a folder.
We’re going to host the application in Kestrel, so before we go any further open the appsetting.json file from the publish folder and add the following
"Kestrel": {
"EndPoints": {
"Http": {
"Url": "http://0.0.0.0:5000"
}
}
},
Now we’ll make the changes to the Dockerfile to copy the published folder to the image and start up the Kestrel server when the image is run, here’s the Dockerfile
FROM mcr.microsoft.com/dotnet/core/sdk:3.1
ENV APP_HOME /home
RUN mkdir -p $APP_HOME
WORKDIR $APP_HOME
COPY ./BlazorServer/BlazorServer/publish ${APP_HOME}
EXPOSE 5000
CMD [ "dotnet", "BlazorServer.dll" ]
Now you should be able to access your server using http://your_server_name:5000.
I wanted to create a docker build to run a spring boot based application along with it’s mongodb database which proved interesting. Here’s what I fouand out.
Dockerfile
To begin with, we need to create a docker configuration file, named Dockerfile. This will be used to create a docker image which we will host a spring boot JAR. Obviously this will require that we create an image based upon a Java image (or create our own). So let’s base our image on a light weight open JDK 1.8 image, openjdk:8-apline.
Below is an example Dockerfile
FROM openjdk:8-alpine MAINTAINER putridparrot RUN apk update ENV APP_HOME /home RUN mkdir -p $APP_HOME ADD putridparrot.jar $APP_HOME/putridparrot.jar WORKDIR $APP_HOME EXPOSE 8080 CMD ["java","-Dspring.data.mongodb.uri=mongodb://db:27017/","-jar","/home/putridparrot.jar"]
The above will be used to create our image, based upon openjdk:8-apline, we then run an update (in case its required) we create an environment variable for our application folder (we’ll simply install our application into /home, but it could be more specific, such as /home/putridparrot/app or whatever), we then create that folder.
Next we ADD our JAR, so this is going to in essence copy our JAR from our host machine into the docker image so that when we run the image it’ll also include the JAR within that image.
I’m also exposing port 8080 as my JAR will be exposing port 8080, hence when we interact with port 8080 docker will proxy it through to our JAR application.
Finally we add a command (CMD) which will run when the docker image is run. So in this case we run the executable JAR passing in some configuration to allow it to access a mongodb instance (which will be running in another docker instance.
Note: The use if the db host is important. It need not be named db but the name needs to be the same as we’ll be using within the upcoming docker-compose.yml file
Before we move onto the mongodb container we need to try to build our Dockerfile, here’s the commands
docker rmi putridparrot --force docker build -t putridparrot .
Note: These commands should be run from the folder containing our Dockerfile.
The first command will force remove any existing images and the second command will then build the docker image.
docker-compose.yml
So we’ve created a Dockerfile which will be used to create our docker image but we now want to create a docker-compose file which will be used to run both our newly created image and then a mongodb image and by use of commands such as depends_on and the use of the name of our mongo service (which we used within the JAR execution command). Here’s the docker-compose.yml file
version: "3.1"
services:
putridparrot:
build: .
restart: always
ports:
- "8080:8080"
depends_on:
- db
db:
image: mongo
volumes:
- ./data:/data/db
ports:
- "27017:27017"
restart: always
The first line simply sets the version of the docker-compose syntax, in this case 3.1. This is followed by the services which will be run by docker-compose. The first service listed is our JAR’s image. In fact we do not use the image, we rebuild it (if required) via the build command – this looks for a Dockerfile in the supplied folder (in this case we assume it’s in the same folder as the docker-compose.yml file). We then set up the port forwarding to the docker image. This service depends on a mongodb running, hence the depends_on option.
The next service is our mongodb image. As mentioned previously, the name here can be whatever you want, but to allow our other service connect to it, should be used within our JAR configuration. Think of it this way – this name is the hostname of the mongodb service and docker will handle the name resolution between docker instances.
Finally, we obviously use the mongo image, and we want to expose the ports to allow access to the running instance and also store the data from the mongodb on our host machine, hence allow it to be used when a new instance of this service is started.
Now we need to run docker-compose using
docker-compose up
If all goes well, this will then, possibly build a new image of our JAR, the will bring up the services. As the first service depends_on the second, it will in essence be executed once the mongodb service is up and running, obviously allow it to then connect to the database.
As you’ve probably realised from previous posts, I’m very much into the idea of deploying my server applications via Docker, so let’s take the VertxTest application and create a Docker image with it.
Thankfully we do not need to start our Dockerfile by creating a base OS then adding Java etc. The people writing Vert.x have kindly implemented a base image for us.
See Deploying a Java verticle in a docker container.
If we take the example Dockerfile from their website and make the changes for our application (just replace VERTICAL_NAME and VERTICLE_FILE with our main verticle and the JAR) we get the following file
FROM vertx/vertx3 ENV VERTICLE_NAME com.putridparrot.MainVerticle ENV VERTICLE_FILE VertxTest-1.0-SNAPSHOT-fat.jar ENV VERTICLE_HOME . EXPOSE 8080 COPY $VERTICLE_FILE $VERTICLE_HOME/ WORKDIR $VERTICLE_HOME ENTRYPOINT ["sh", "-c"] CMD ["exec vertx run $VERTICLE_NAME -cp $VERTICLE_HOME/*"]
Place this Dockerfile into a folder along with the compiled JAR and then execute
docker build -t vertx_test .
This creates an image name vertx_test which we can now execute. If you want to watch the output from our System.out.println execute
docker run -it -p 8080:8080 vertx_test
Once you see the HTTP server started on port 8080 outputs, the Vert.x application will be ready for you to access via your preferred web browser etc.