I'm hosting a Flutter app with thttpd via Docker.
I'm trying to understand how I can catch all routes, as there doesn't seem to be a configuration and I don't want to go down the Nginx way.
For example domain.com/some-route should load the index, but it does not :-/
FROM alpine:3.16.0
# Install thttpd
RUN apk add thttpd
# Create a non-root user to own the files and run our server
RUN adduser -D static
USER static
WORKDIR /home/static
COPY ./build/web/ /home/static
# Run thttpd
CMD ["thttpd", "-D", "-p", "8080", "-d", "/home/static", "-u", "static", "-l", "-", "-M", "60"]
Related
1.FRONT-END SHOULD RUN ON NGINX.
2.BACK-END
STEP-1 COPY PACKAGE FOLDER FROM BACKEND.
STEP-2 npm install.
STEP-3 npm install -g pm2.
STEP-4 pm2 list.
STEP-5 copy dist,env files from backend.
STEP-6 pm2 start dist/main.js --name backend.
--->pm2 kill for deleting the folder.
--->pm2 monit and pm2 logs for error viewing.
STEP-7: ECOSYSTEM BUILD FOR ERROR LOG AND INSTANCES CREATE:
STEP-8: pm2 init
STEP-9: pm2 start ecosystem.config.js
STEP-10.pm2 save
We have a dockerized golem app that runs fine except for not creating any output (log statements) when deployed in a docker container. In fact, we aren't even seeing any default shiny-server logs.
Here is app.R for our "AirSensorDataViewer" golem app:
pkgload::load_all(export_all = FALSE, helpers = FALSE, attach_testthat = FALSE)
options(
golem.app.prod = TRUE,
shiny.port = 3838,
shiny.host = '0.0.0.0'
)
AirSensorDataViewer::run_app()
And here is our Dockerfile (that builds on top of of a base image with all necessary packages):
FROM mazamascience/airsensor-dataviewer-base:1.0.1
# Create the build zone, copy the local directory over to the docker image, build and install R package.
RUN mkdir /build_zone
ADD . /build_zone
WORKDIR /build_zone
RUN R -e 'remotes::install_local(upgrade="never")'
# Remove sample apps
RUN rm -rf /srv/shiny-server/
# copy app to image
COPY . /srv/shiny-server/asdv
# add .conf file to image/container to preserve log file
COPY ./shiny-server.conf /etc/shiny-server/shiny-server.conf
# When run image and create a container, this container will listen on port 3838
EXPOSE 3838
# Avoiding running as root --> run container as user 'shiny' instead
# allow permission
RUN sudo chown -R shiny:shiny /srv/shiny-server
RUN chmod -R 755 /srv/shiny-server/asdv
# execute in the following as user --> imortant to give permission before that step
USER shiny
##run app
CMD ["/usr/bin/shiny-server.sh"]
And, lastly, our shiny-server.conf file:
# Instruct Shiny Server to run applications as the user "shiny"
run_as shiny;
# Define a server that listens on port 3838
server {
listen 3838;
# Define a location at the base URL
location /asdv/test/ {
# Host the directory of Shiny Apps stored in this directory
site_dir /srv/shiny-server/asdv;
# Log all Shiny output to files in this directory
log_dir /var/log/shiny-server;
# When a user visits the base URL rather than a particular application,
# an index of the applications available in this directory will be shown.
directory_index on;
}
}
Has anyone had success getting a dockerized golem app to create/write to files inside the docker container?
I hope the posted question might be helpful for those wanting to do this as it turns out everything works fine.
For the last few hours I was mistakenly typing docker run ... when I wanted to check the container log files. This creates a new container.
Instead, log files are indeed found in /var/log/shiny-server/ when I:
docker exec -ti airsensor-dataviewer-desktop /bin/bash
ls /var/log/shiny-server/
I am attempting to login to a Docker angular app using Identity Server for Authentication. Once I enter my credentials for on Identity Server, I get a 500 Internal Server Error.
When I run this application locally (non-Docker) I am able to login with ID Server and return to the Angular App without seeing any errors. Which makes me think there must be something wrong with my ID Server Dockerfile:
FROM microsoft/dotnet AS build-env
ARG source
RUN echo "source: $source"
WORKDIR /app
RUN apt-get update
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash
RUN apt-get install nodejs
RUN node -v
RUN npm -v
# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore
#Copy everything else & build
COPY . ./
RUN dotnet publish -c Release -o out
# Build runtime image
FROM microsoft/dotnet
WORKDIR /app
COPY --from=build-env /app/out .
EXPOSE 80
ENTRYPOINT ["dotnet", "IdentityServerWithAspNetIdentity.dll"]
Can anyone tell me why I am seeing a 500 Internal Server Error in Docker, and what I can do to resolve this issue?
Much appreciated, thank you.
I have a containerized R Shiny app that, when run locally with docker run --rm -p 3838:3838 [image] works as expected. The "landing" page appears when I go to localhost:3838 and all is good. However, when this container is deployed to AWS Fargate, things break down. The container appears to start and run, but there's no webpage being served on 3838 even though all ports are pointed to 3838 in Fargate.
I'm using dockerfile
FROM rocker/verse:3.5.1
LABEL Steven "email"
## Add shiny capabilities to container
RUN export ADD=shiny && bash /etc/cont-init.d/add
## Update and install
RUN tlmgr update --self
RUN tlmgr install beamer translator
## Add R packages
RUN R -e "install.packages(c('shiny', 'googleAuthR', 'dplyr', 'googleAnalyticsR', 'knitr', 'rmarkdown', 'jsonlite', 'scales', 'ggplot2', 'reshape2', 'Cairo', 'tinytex'), repos = 'https://cran.rstudio.com/')"
#Copy app dir and them dirs to their respective locations
COPY app /srv/shiny-server/ga-reporter
COPY app/report/themes/SwCustom /opt/TinyTeX/texmf-dist/tex/latex/beamer/
#Force texlive to find my custom beamer thems
RUN texhash
EXPOSE 3838
## Add shiny-server information
COPY shiny-server.sh /usr/bin/shiny-server.sh
COPY shiny-customized.config /etc/shiny-server/shiny-server.conf
## Add dos2unix to eliminate Win-style line-endings and run
RUN apt-get update && apt-get install -y dos2unix
RUN dos2unix /usr/bin/shiny-server.sh && apt-get --purge remove -y dos2unix && rm -rf /var/lib/apt/lists/*
RUN ["chmod", "+x", "/usr/bin/shiny-server.sh"]
CMD ["/usr/bin/shiny-server.sh"]
and shiny-server.conf
# Instruct Shiny Server to run applications as the user "shiny"
run_as shiny;
# Define a server that listens on port 3838
server {
listen 3838;
# Define a location at the base URL
location / {
# Host the directory of Shiny Apps stored in this directory
app_dir /srv/shiny-server/ga-reporter;
# Log all Shiny output to files in this directory
log_dir /var/log/shiny-server;
# When a user visits the base URL rather than a particular application,
# an index of the applications available in this directory will be shown.
directory_index on;
}
}
with shiny-server.sh
#!/bin/sh
# ShinyServer: Make sure the directory for individual app logs exists
mkdir -p /var/log/shiny-server
chown -R shiny.shiny /var/log/shiny-server
# RUN ShinyServer
exec shiny-server >> /var/log/shiny-server.log 2>&1
I have edited the .conf file to display the app (i.e., location /) in /srv/shiny-server/ga-reporter which is also where I've copied the app_dir in the Dockerfile. Shiny is listening on port 3838 and should serve the page there. Again, this happens locally but not when deployed to AWS Fargate. I've tried logging Shiny logs to stdout by using the first answer provided here but have had no luck seeing any errors generated. Server "health checking" is only offered in the "pro" version so I can't check to see if the server is actually running.
On AWS, the container starts and appears to function normally (i.e., the "normal" start up logs appear):
but there is simply no page displayed at the location I expect it to be served.
I found another Shiny app that is on dockerhub running under the same configuration as the Fargate cluster but have had no luck trying to implement anything in the shiny-server.conf or the shiny-server.sh files located there.
What am I missing? Everything on Fargate is pointed to listening on 3838; there must be something I'm missing in the .conf file for this to be failing when deployed.
EDIT
I can't bash in to the running container on Fargate because I don't have access to the server on which docker is running.
Fargate has a UI that accepts host and container ports:
EDIT 2 (2018-08-27)
The engineer that was deploying this has been able to resolve the issue:
"it was the port change, I forgot to can the port on the ALB’s security group, I only updated the cluster’s inbound rules
so the cluster was allowing connections, but the ALB security group wasn’t letting it out"
I'm currently trying to launch a Docker component with a ASP.NET Core application.
I use the following repo for my test : https://github.com/aspnet/cli-samples
I ran the following commande without any issue :
git clone https://github.com/aspnet/cli-samples aspnet-Home
cd aspnet-Home/HelloWeb
cat Dockerfile
FROM microsoft/aspnetcore
WORKDIR /app
COPY . .
ENTRYPOINT ["dotnet", "helloweb.dll"]
sudo docker build –t helloweb .
sudo docker run -d helloweb
The image is visible using the sudo docker images, but the container doesn't launch and is not visible with sudo docker ps:
And if I browse my website, obsviously I do not see data.
Is the repo not good for my test ? Is there any mistake I do on the docker container creation ?
Running the -it command give me the following output:
The error you highlighted is because helloweb.dll you set as the ENTRYPOINT doesn't exist. There could be two reasons for it
1 You didn't build the project yet
In this case you should run dotnet restore from the project home directory, then navigate to HelloWeb directory and run dotnet publish. When I run this command, I see the following:
publish: Published to /code/HelloWeb/bin/Debug/netcoreapp1.0/publish
Published 1/1 projects successfully
2 You built the project, but the ENTRYPOINT path is wrong
COPY . . directive will copy everything from the current directory into your app directory. That means HelloWeb.dll will actually be in bin/Debug/netcoreapp1.0/publish/ (or bin/Release/... for release builds).
Option 1: Modify your entrypoint with the full path
ENTRYPOINT ["dotnet", "bin/Debug/netcoreapp1.0/publish/HelloWeb.dll"]
Your application should happily start and serve requests.
Option 2: Modify your COPY directive
Once your project has been published, everything you'll need to run it will be in the publish directory. You could copy the contents of that into the /app directory and your entrypoint will be correct. That would look like this
FROM microsoft/aspnetcore
WORKDIR /app
COPY ./bin/Debug/netcoreapp1.0/publish/ .
EXPOSE 80
ENTRYPOINT ["dotnet", "HelloWeb.dll"]
You will also probably want to add the EXPOSE directive to tell Docker that your container will be listening on port 80.
When that succeeds, you should see (if you run in interactive mode)
docker run -it helloweb
Hosting environment: Production
Content root path: /app
Now listening on: http://+:80
Application started. Press Ctrl+C to shut down.
You could also use the microsoft/dotnet:latest image instead. That image comes with the SDK installed and a very convenient run command. The Dockerfile would look like this
FROM microsoft/dotnet:latest
COPY . /app
WORKDIR /app
RUN dotnet restore
ENV ASPNETCORE_URLS http://*:5000
EXPOSE 5000
ENTRYPOINT ["dotnet", "run"]
and you should be able to modify your source and build and run your container.