Closed Kingcitaldo125 closed 4 years ago
Looking through my documentation and various repos, I'm realising that there are actually very few example Dockerfiles available:
There's one example on the CI/CD page of the Unreal Containers community hub documentation: https://unrealcontainers.com/docs/use-cases/continuous-integration#building-container-images-for-deployment
There's a Pixel Streaming-specific example in my article about Pixel Streaming for Linux: https://adamrehn.com/articles/pixel-streaming-in-linux-containers/#building-container-images
There are Dockerfiles for my old UE4Capture-based rendering demo and my gRPC microservice demo, but those are both extremely specific to their relevant demo projects and also buried under subdirectories in source trees, which makes them difficult to discover in the first place.
I think you're absolutely right that I should add a directory full of examples for various scenarios, although I might create a separate repository for that and link to it from the ue4-runtime README rather than embed it inside this repository, since the examples could also include Dockerfiles that don't use the ue4-runtime base image (e.g. directly using NVIDIA base images.)
As for your own Dockerfile, it can be simplified to this:
FROM adamrehn/ue4-runtime:latest
# Copy the packaged files into the image and assign ownership to the non-root ue4 user
WORKDIR /home/ue4
COPY --chown=ue4:ue4 LinuxNoEditor/ .
# Set the project's startup script as the container entrypoint
ENTRYPOINT [ "/home/ue4/MyProject.sh" ]
Notes:
There's no need to run anything as root, since the project should be owned by, and run using, the non-root ue4
user account.
It shouldn't be necessary to add the execute permission to the shell script if your host system is running Linux, since filesystem permissions are preserved when copying files into the container image (this step would however be necessary if you were cross-compiling for Linux under a Windows host system and then copying the files into a Linux container image, since the Windows filesystem won't preserve the executable bit.)
I believe either CMD
or ENTRYPOINT
should work happily for the last directive in the Dockerfile, since the script that gets generated by the Unreal Engine will work with either sh
(which should be used to run it if you specify ENTRYPOINT
) or bash
(which should be used to run it if you specify CMD
, since I believe bash
is the default entrypoint for Ubuntu-based container images.)
There's no need to specify the visible GPU devices, since all
is the default value.
There's no need to add video
to the NVIDIA driver capabilities, unless you need to encode video using the NVENC API.
Thanks for this information. This is very helpful. It looks like my original issue appeared to be, more or less, related to getting my Linux VM to accept being able to run the startup scripts without permission errors. Sorry if parts of that Dockerfile, and my particular issue case, were somewhat out of scope.
Thanks also for the examples that you've mentioned. I think the biggest issue here was related to my docker naivety. I'm used to working within the Unreal Engine itself instead of trying to package and run projects in unfamiliar contexts. The goal was to package a UE4 project, that was made in a Windows 10 environment, to run within a Linux container environment using the ue4-runtime image.
Thanks again,
Paul A
@Kingcitaldo125 the repository with example Dockerfiles is now live: https://github.com/adamrehn/ue4-example-dockerfiles. The initial set of examples are quite basic but I'll continue to expand it with various use cases as time goes on.
Thanks for uploading those examples. They provide some helpful contextual information. I also think that those examples would be helpful when it comes to testing the integrity of UE4 projects from a docker context like you've mentioned from within a Dockerfile in that examples repo.
Would you happen to know how much time it would be before a cloud rendering example Dockerfile/configuration would be available in the example repository? Our current use case reflects something very similar to Pixel Streaming, but rather exporting images(PNG) of a video feed to a local data store instead of the strict Pixel Streaming paradigm.
Thanks, Paul A
I've got a few ideas around different cloud rendering and microservice examples to put together and add to the repository, but I'm still thinking about the best way to generalise them.
In your particular case, you could likely use the Dockerfile for the Pixel Streaming application and remove the Pixel Streaming-specific lines (the environment variable and the symbolic link) to create a container image for your packaged project. You'd just need to add an EXPOSE directive for whatever TCP or UDP ports that your application listens on for incoming network communication.
Hello, I'm currently trying to use the ue4-runtime image to create my own container that runs a UE4 project that was packaged for Linux, but I'm having some trouble. I'm not sure if this issue is out of scope for the ue4-runtime container, but I wanted to make sure just in case it was related to the runtime image. I'm currently trying to build an Unreal Engine project, package it for Linux, then run that packaged Linux project in a container using the ue4-runtime image as a base image.
Is there a preferred method for running/building containers that contain packaged projects using this paradigm? Are there examples that show how to create a custom Dockerfile using ue4-runtime as a base image? If there aren't examples of how to do this, I think it would be helpful to add an examples/ folder to the repo for different cases.
I'll attach my dockerfile to help explain my thought process.
Thanks and please advise, Paul A