Docker best practices as of March 2017?

104 views
Skip to first unread message

Damian Nadales

unread,
Mar 29, 2017, 9:28:54 AM3/29/17
to Commercial Haskell
Hi,

I finally got the chance of developing a Haskell based web-service at
the company where I'm working. The service involves some interface
with a Postgres database and an MQTT broker, for which Haskell seems
to have some supporting libraries. To be able to make this service
usable I need to place it in a docker container during the "deploy"
stage of our Jenkins pipeline.

I've made a preliminary experiment using stack's docker support:
building a docker container can be readily achieved by `stack image
container`, and I've plugged the generated container into our
`docker-compose.yml` file, which describes the docker containers used
in our local development environment. So far the relevant setup looks
as follows:

stack.yaml:

resolver: lts-8.5

docker:
auto-pull: false

image:
container:
name: my-service
base: fpco/stack-run

docker-compose.yml

my-service:
container_name: my-service
image: my-service
links:
- my-service-db
entrypoint:
- /usr/local/bin/my-service-exe

I have some concerns with the setup above:
0. I'm using a no longer maintained image, namely fpco/stack-run.
1. I cannot specify the generated container image name based on
the `version` field in the .cabal file.
2. I have to specify an entry point in the generated container
(could I just use `entrypoints` in the `stack.yaml` configuration?)

Based on these concerns I wanted to ask you how would you address it,
or whether you have better suggestions for dockerizing your Haskell
applications.

The second question relates to the "deploy from Jenkins" requirement.
In our current setup, every build step is executed from within a
container, so installing stack in Jenkins is not a possibility. So
this means that I'd have to run the `stack image container` from
within a docker container (fpco/stack-build most likely), which in
turn will spawn another fpco/stack-build container inside the first
one to start the creation of the container. This is quite cumbersome,
but I see no better alternative given the constraint mentioned above.
Do you have any suggestions?

Finally, the resulting image will have to be pushed to a docker
registry hosted on AWS. For this the best I have now is to do it via a
shell script (or Turtle) since as far as I can see stack has no
support for publishing images. How do you publish your containers to
private registries?

Thanks in advance
Damian.

Alfredo Di Napoli

unread,
Mar 30, 2017, 2:14:12 AM3/30/17
to Commercial Haskell, damian....@gmail.com
Hey Damian!

I don't know if it will answer your question entirely, but this is the approach I have been using at work with success:


It still requires to bundle your app using a "proprietary" Docker image (but only for conveniency as, in theory,
you are in control) but it has the advantage that, at the end of the process, you end up with (essentially) a cross-compiled
executable.

I hope it can be of any use for you, if not just for taking inspiration from.

Alfredo

Damian Nadales

unread,
Apr 2, 2017, 3:21:39 AM4/2/17
to Alfredo Di Napoli, Commercial Haskell
Hi Alfredo,

I don't think I have the flexibility to adapt our workflow to the way
it is described in your post, but I'll see what I can use for
inspiration. I like the fact that you use native executables, and
apparently that works well for you.

Thanks a lot.
Damian.
> --
> You received this message because you are subscribed to the Google Groups
> "Commercial Haskell" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to commercialhask...@googlegroups.com.
> To post to this group, send email to commerci...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/commercialhaskell/add028f4-0ed6-4fd4-b577-0b857d5bd5d0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages