Docker best practices as of March 2017?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Docker best practices as of March 2017?

Damian Nadales
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.

--





Reply | Threaded
Open this post in threaded view
|

Re: Docker best practices as of March 2017?

Alfredo Di Napoli
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:

http://www.alfredodinapoli.com/posts/2015-11-03-how-i-deploy-haskell-code.html

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

On Wednesday, March 29, 2017 at 3:28:54 PM UTC+2, Damian Nadales wrote:
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.

--
Reply | Threaded
Open this post in threaded view
|

Re: Docker best practices as of March 2017?

Damian Nadales
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.

On Thu, Mar 30, 2017 at 8:14 AM, Alfredo Di Napoli
<[hidden email]> wrote:

> 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:
>
> http://www.alfredodinapoli.com/posts/2015-11-03-how-i-deploy-haskell-code.html
>
> 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
>
>
> On Wednesday, March 29, 2017 at 3:28:54 PM UTC+2, Damian Nadales wrote:
>>
>> 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.
>
> --
>
> "Commercial Haskell" group.
>
> email to [hidden email].
>
>
> https://groups.google.com/d/msgid/commercialhaskell/add028f4-0ed6-4fd4-b577-0b857d5bd5d0%40googlegroups.com.
>

--