nasa / trick

Trick Simulation Environment. Trick provides a common set of simulation capabilities and utilities to build simulations automatically.
Other
45 stars 22 forks source link

QUESTION: Docker Container For Trying Trick #781

Open astroesteban opened 5 years ago

astroesteban commented 5 years ago

Docker containers have become incredibly popular in providing a portable and reproducible solution to distributing applications and software.

Are there plans to create a Docker image that would allow a user to download and execute the Dockerfile and have a working Trick environment to play around with?

alexlin0 commented 5 years ago

We use docker containers to run all of our continuous integration testing. We are investigating the best way to share our containers.

astroesteban commented 5 years ago

That's awesome. We use a Docker/Vagrant combo to run our Trick simulations.

alexlin0 commented 5 years ago

OK, this is a first test, try these images on dockerhub:

https://cloud.docker.com/u/nasatrick/repository/docker/nasatrick/trick_centos7

https://cloud.docker.com/u/nasatrick/repository/docker/nasatrick/trick_ubuntu1804

These are essentially the images we use for continuous integration (CI). We do not run the GUIs in our CI images. Further docker work may be required to get GUIs to work.

astroesteban commented 5 years ago

Thanks for this @alexlin0. I'll check the images out and provide some feedback.

The solutions I've seen for adding GUI support involves adding some X server forwarding support. It's definitely not a painless solution.

astroesteban commented 5 years ago

Hey @alexlin0, I have been testing out the Ubuntu image and it has been working great. I am able to build the Trick examples without any issues and even rebuild Trick itself.

One minor thing I noticed is that the Docker Hub website provides the docker pull nasatrick/trick_ubuntu1804 command. This command appends :latest to the image name instead of :17.5.0, but since there is no image tagged as latest, the Docker daemon errors out.

alexlin0 commented 5 years ago

Thanks for the feedback. I'll add a latest tag, I'll research how other projects do it.

alexlin0 commented 5 years ago

Ok, it appears that I retag images as the "latest" and push them. I've done that and I see them on dockerhub now.

astroesteban commented 5 years ago

Thanks @alexlin0. That feature works now. I'll see how we can integrate it into some of our workflows to keep testing it out.

apshoemaker commented 4 years ago

As it doesn't appear that the Dockerfile is published to DockerHub for the above locations, here is my minimal setup that I'm playing around with. I haven't spent a ton of time on this (maybe 30 - 45 min to try it out?) and there are many many improvements that can be made, but it might give someone a jumping off point:

FROM ubuntu:18.04

RUN apt-get update && apt-get install -y bison curl flex g++ libx11-dev libxml2-dev libxt-dev \
 libmotif-common libmotif-dev make openjdk-8-jdk python2.7-dev swig \
 zlib1g-dev llvm llvm-dev clang libclang-dev libudunits2-dev

RUN mkdir /app
RUN mkdir /app/sim
ADD . /app

WORKDIR /app

RUN /app/configure && make && make install

ENTRYPOINT ["trick-CP", "-C", "/app/sim"]

You can run with the following:

docker image build -t trick:1.0 . docker run --rm -it -v ${PWD}:/app/sim trick:1.0

Where ${PWD} might be the location of your simulation.

Again - just a jump-off point while I played around with the compiler app a bit.

CDKnightNASA commented 3 years ago

I'm curious if anybody's developed a "headless build" for use in a containerized environment--loading all those X11 rpm's takes time/space.

cazlo commented 5 months ago

Thanks for this @alexlin0. I'll check the images out and provide some feedback.

The solutions I've seen for adding GUI support involves adding some X server forwarding support. It's definitely not a painless solution.

There are many ways to run X server completely within a container, with no X forwarding necessary. Without GPU acceleration this isn't a huge pain, but with GPU acceleration you have to make GPU driver specific images and runtimes.

I have about 4 different, working solutions for this task described in open source code here: https://github.com/cazlo/gl-vdi-containers/pull/1

I'm also interested in trying to run this tool, but don't really want to install a bunch of stuff directly on my machine without sandbox. So I'll build a few containerized examples of:

which is being discussed in this thread.