For the first case, I followed a blog post and it's recommended adding Java and Docker plugins in the build.sbt file like:
enablePlugins(JavaAppPackaging)
enablePlugins(DockerPlugin)
dockerBaseImage := "openjdk:8"
dockerEntrypoint := Seq("bin/test", "-Denv=dev")
however, it seems to build an unstable image, the container fails to start with an error:
Oops, cannot start the server.
java.nio.file.AccessDeniedException: /opt/docker/RUNNING_PID
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434)
at java.nio.file.Files.newOutputStream(Files.java:216)
at play.core.server.ProdServerStart$.createPidFile(ProdServerStart.scala:148)
at play.core.server.ProdServerStart$.start(ProdServerStart.scala:46)
at play.core.server.ProdServerStart$.main(ProdServerStart.scala:30)
at play.core.server.ProdServerStart.main(ProdServerStart.scala)
Can someone help me out on this or on using a Dockerfile instead.
I managed to figure out using Dockerfile; I wrote a Dockerfile in the root directory, the use docker build command
FROM openjdk:8-jdk
#Add build artifacts into stage dir
ADD target/universal/stage stage
EXPOSE 9000
CMD ["stage/bin/play2_app", "-Dplay.http.secret.key=abcdef12345"]
Then build the image:
$ docker build -t play2-test-app:v1 .
Run the docker image locally
$ docker run -d --name play2-test-container -p 9000:9000 [images id]
First ensure the container is running by listing all running containers:
$ docker ps
View your app on browser at:
localhost:9000
Related
I am starting to use kubernetes/Minikube to deploy my application which is currently running on docker containers.
Docker version:19.03.7
Minikube version: v1.25.2
From what I read I gather that first of all I need to build my frontend/backend images inside minikube.
The image is available on the server and I can see it using:
$ docker image ls
The first step, as far as I understand, is to use the "docker build" command:
$docke build -t my-image .
However, the dot at the end, so I understand, means it is looking for a Dockerfile in the curretn directoy, and indeed I get an error:
unable to evaluate symlinks in Dockerfile path: lstat
/home/dep/k8s-config/Dockerfile: no such file or directory
So, where do I get this dockerfile for the "docker build" to succeed?
Thanks
My missunderstanding...
I have the Dockefile now, so I should put it anywhere and use docker build from there.
I am using Visual Code with Azure Core Tools to deploy a container to a K8S cluster which has KEDA installed. But seeing this docker error. The error is caused because the docker build is run without the double quotes.
$ func kubernetes deploy --name bollaservicebusfunc --registry sbolladockerhub --python
Running 'docker build -t sbolladockerhub/bollaservicebusfunc C:\Users\20835918\work\welcome to space'....done
Error running docker build -t sbolladockerhub/bollaservicebusfunc C:\Users\20835918\work\welcome to space.
output:
"docker build" requires exactly 1 argument.
See 'docker build --help'.
Usage: docker build [OPTIONS] PATH | URL | -
Build an image from a Dockerfile
(.venv)
20835918#CROC1LWPF1S99JJ MINGW64 ~/work/welcome to space (master)
I know there is a known bug Spaces in directory
But posting to see if there is a workaround, this is important as I have eveything in Onedrive - Comapny Name and it has spaces in it
Looking into the code for func, you could specify --image-name instead of --registry which seems to skip building the container.
You would have to build your docker container manually using the same code shown in the output and provide the value for the -t argument of the docker command for --image-name of the func command after.
Also, since this would not push your docker container as well, make sure to push it before running the func command.
I am trying to run an ASP.net core API in a Docker container. Running from Visual Studio works perfectly fine, but I cant access the API when I run it using the following powershell command:
docker run --name test6 --rm -it -p 9001:80 webapplication6:dev
It just return:
root#874b63595efc:/app#
I expect that it will show me that it has started listening to the given port. I tried to use an existing repo from Docker Hub to do a test:
docker run --name aspnetcore_sample --rm -it -p 8000:80 mcr.microsoft.com/dotnet/core/samples:aspnetapp
And it successfully returned the following:
info: Microsoft.Hosting.Lifetime[0]
Now listening on: http://[::]:80
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
Content root path: /app
It is accessible in my localhost. Going back to my test API project, I have the following text in my Dockerfile:
FROM mcr.microsoft.com/dotnet/core/aspnet:2.1-stretch-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/core/sdk:2.1-stretch AS build
WORKDIR /src
COPY ["WebApplication6.csproj", ""]
RUN dotnet restore "./WebApplication6.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "WebApplication6.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "WebApplication6.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication6.dll"]
This was automatically added by Visual Studio.
Here is the output being returned by docker ps
The command value for my test application is "bash". Do I need to configure anything else for me to run the API container using Powershell alone and without using Visual Studio?
Seems like docker engine is ignoring the entrypoint directive in your Dockerfile, as you can see the command is null in your running container.
You can probably work around this issue by specifying a CMD directive in your Dockerfile. Try adding this line to the bottom of your Dockerfile and see if it helps:
CMD ["dotnet", "WebApplication6.dll"]
Also, make sure that your docker image is built with the current version of the Dockerfile, you can try using this command to verify that:
docker build -t webapplication6:dev .
I need to change the locale of the offical Postgres(11.4) image in order to create databases with my language.
https://github.com/docker-library/postgres/blob/87b15b6c65ba985ac958e7b35ba787422113066e/11/Dockerfile
I copied the Dockerfile and docker-entrypoint.sh from offical postgres image( I did not add the customization yet)
aek#ubuntu:~/Desktop/Docker$ ls
docker-entrypoint.sh Dockerfile
aek#ubuntu:~/Desktop/Docker$ sudo docker build -t postgres_custom .
Step 24/24 : CMD ["postgres"]
---> Running in 8720b67094b1
Removing intermediate container 8720b67094b1
---> eb63a36ee850
Successfully built eb63a36ee850
Successfully tagged postgres_custom:latest
Image is successfully built but when I try to run it I get error below:
aek#ubuntu:~/Desktop/Docker$ docker run --name postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres_custom
d75b25367f019e3398f7daff78260e87c02a0c1898658585ec04bbd219bbe3e9
docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"docker-entrypoint.sh\": executable file not found in $PATH": unknown.
Can't figure out what is wrong with the entrypoint.sh. Can you please help me?
you need to make entrypoint.sh executable :
RUN chmod +x /path/to/entrypoint.sh
as you said that you copied it without any further changes.
I have an asp.net core 2.0 application whose docker image runs fine locally, but when that same image is deployed to an AKS cluster, the pods have a status of CrashLoopBackOff and the pod log shows:
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409.
And since you can't ssh to AKS clusters, it's pretty difficult to figure this out?
Dockerfile:
FROM microsoft/aspnetcore:2.0
WORKDIR /app
COPY . .
EXPOSE 80
ENTRYPOINT ["dotnet", "myapi.dll"]
Turned out that our build system wasn't putting the app code into the container as we thought. Since the container wasn't runnable, I didn't know how to inspect its contents until I found this command which is a lifesaver for these kinds of situations:
docker run --rm -it --entrypoint=/bin/bash [image_id]
... which at this point, you can freely inspect/verify the contents of the container.
I just ran into the same issue and it's because I was missing a key piece to the puzzle.
docker-compose -f docker-compose.ci.build.yml run ci-build
VS2017 Docker Tools will create that docker-compose.ci.build.yml file. After that command is run, the publish folder is populated and docker build -t <tag> will build a populated image (without an empty /app folder).