Skip to content

Instantly share code, notes, and snippets.

@MggMuggins
Created April 19, 2018 02:59
Show Gist options
  • Save MggMuggins/f88175f6c7859f0b3c0261e83bf16762 to your computer and use it in GitHub Desktop.
Save MggMuggins/f88175f6c7859f0b3c0261e83bf16762 to your computer and use it in GitHub Desktop.
Docker things
FROM andrewbenton/alpine-ldc
RUN adduser coder -h /home/coder -D
ADD --chown=coder:coder code /home/coder/code.d
WORKDIR /home/coder
RUN sed -i '1s/^/void main() {\n/' code.d
RUN sed -i '$s/$/\n}/' code.d
USER coder:coder
CMD ["/ldc/bin/ldc", "-of", "code", "code.d", "&&", "/home/coder/code"]
USER root:root

Dockerfile

The above dockerfile is probably accurate. As you can see there is some stuff going on in the backend when this container is built, so it's not a complete picture of what is going on, but it gets the gist of the thing across I think. Note that I'm pretty new to docker, so there's some things in there that probably don't make sense.

Error

The errors I'm getting are really just /bin/sh: can't open '...'. However, replacing CMD with something basic, like echo or ls doesn't fix that issue. However, having done a little testing, setting ENTRYPOINT doesn't have any effect, just changes the name the sh binary uses to report errors...

@andrewbenton
Copy link

Sorry I'm just getting to this, but I think I've worked out a few issues in your example. Without the contents of your home directory, it's difficult to say for certain whether these fixes will work for you, but here's a list of the issues / fixes. I imagine that the code.d from the above example could easily replace the test.d from the below example.

  1. The general idea for this alpine-ldc image is to serve as the first layer in a multi stage build. You should be basing your first layer off of andrewbenton/alpine-ldc and building your binary in that layer before passing it off to your final layer for running.
  2. The docker image probably doesn't need to reflect your home directory unless your binary requires the home directory for execution.
  3. I'm pretty sure that adding a USER statement after the CMD is effectively a no-op.
  4. A dub.json / dub.sdl needs to be provided that adds "ldc-flags": [ "-static" ] to the properties so that a static binary is produced.
  5. Supplying the && in the list of arguments to CMD is just treated as another argument to /ldc/bin/ldc instead of allowing execution of a subsequent command, which I believe is the intended effect.

Small example below:

./source/test.d:

import std.stdio;
import std.range;

int main(string[] args) {
    args.retro.writeln;
    return 0;
}

./Dockerfile.ldc-test:

FROM andrewbenton/alpine-ldc:v1.8.0 as packager

COPY . /src

RUN \
    cd /src && \
    if [ -e .dub ]; then rm -rf .dub; fi && \
    dub build --build release

FROM alpine:3.7

RUN \
    adduser andrew -D -H

USER andrew

COPY --from=packager --chown=andrew:andrew /src/test /test

CMD [ "/test", "&&", "echo", "a"]

./dub.json:

{
    "name": "test",
    "authors": [
        "Andrew Benton"
    ],
    "description": "A minimal D application.",
    "copyright": "Copyright © 2018, Andrew Benton",
    "license": "proprietary",
    "targetType": "executable",
    "dflags-ldc": [ "-static" ]
}

Build with: docker build -f Dockerfile.ldc-test -t run-issue .
Run with: docker run -it --rm run-issue:latest or docker run -it --rm run-issue:latest /test a b c d e f g

Please let me know whether that was helpful or not. I'd like to resolve your issue if I can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment