search

openenergysolutions / openfmb.adapters

OpenFMB Adapters
Apache License 2.0
3 stars 1 forks source link

Docker scratch #87

Closed jadamcrain closed 4 years ago

jadamcrain commented 4 years ago

Provide Scratch builds w/ complete statically linked executable instead of Alpine.

Investigate the possibility of cross compiling a fully static ARM7 executable and scratch image instead of using QEMU.

emgre commented 4 years ago

Scratch Dockerfiles are available in the feature/scratch branch. There is an x64 and an ARM version (done via QEMU).

For cross-compiling, the target is ARMv7 with hardware FPU with the following features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32.

dwaynebradley commented 4 years ago

Just a quick thought...

We may want to do a separate dev build and a release build of the containers. The reason is the scratch base layer prevents us from being able to docker exec -it into the running container for debugging purposes as there is no shell any longer. If we do the release build with scratch and the dev build with Alpine/minideb/etc, that should give us flexibility for debugging plus keep things clean and somewhat more secure for prod/release.

Thoughts???

I actually should have thought about this earlier...sorry about that...

larrylackey commented 4 years ago

All, yes, debug can be handy in test. If we do that then, the only release build would be for the User Group 2018 UML, as by definition what the User Group does in the coming months and what Spokane is doing now is not release. Larry

On Thursday, November 21, 2019, 3:12:55 PM MST, Dwayne Bradley <notifications@github.com> wrote:

Just a quick thought...

We may want to do a separate dev build and a release build of the containers. The reason is the scratch base layer prevents us from being able to docker exec -it into the running container for debugging purposes as there is no shell any longer. If we do the release build with scratch and the dev build with Alpine/minideb/etc, that should give us flexibility for debugging plus keep things clean and somewhat more secure for prod/release.

Thoughts???

I actually should have thought about this earlier...sorry about that...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

emgre commented 4 years ago

What kind of debugging are you doing in the container? Are you running GDB inside of it? I know that running GDB inside of a Docker container is a pain, so I would perhaps recommend to just ditch Docker at this point and just run the adapter without an hypervisor when debugging. Since it's statically linked, you can just copy-paste the executable that will be built by CircleCI (it will be stored in artifacts like this: https://app.circleci.com/jobs/github/openenergysolutions/openfmb.adapters/88/artifacts) and play with it. My goal is to provide both the executable and the Docker image on each build as artifacts.

The Docker container, even in Alpine/minideb, is just the executable, the RTI license and that's it. If Docker is a burden when debugging, then simply run the adapter without it.