# Selective Docker Compose

**URL:** <https://forums.balena.io/t/selective-docker-compose/37746>\
**Category:** balenaOS\
**Tags:** raspberrypi3, docker, docker-compose, raspberrypizero\
**Created:** [October 18, 2019, 6:12pm UTC](https://forums.balena.io/t/selective-docker-compose/37746 "2019-10-18T18:12:09Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![AdamLee](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/adamlee/32/2149_2.png) [@AdamLee](https://forums.balena.io/u/AdamLee)\
**Post date:** [October 18, 2019, 6:12pm UTC](https://forums.balena.io/t/selective-docker-compose/37746/1 "2019-10-18T18:12:09Z")

</div>

We’ve got a use case EXTREMELY similar to the following thread where we have one version of our application that runs an integrated app/api with an attached screen and then one that runs with only the api and communicates over TCP/IP.

> [@Selectively running containers on a device](https://forums.balena.io/t/selectively-running-containers-on-a-device/16086):
>
> I figured I’d pose the question here first before descending down a rabbit hole. Here’s the hypothetical situation. I have two devices, deviceOne and deviceTwo, both of which are a Rpi3 running BalenaOS. Both devices run the same BalenaCloud application, however each has a different functional use. Eg. deviceOne has a screen attached and deviceTwo reads a sensor. I have two services that run as part of the app, let’s call them kiosk and sensor. In theory, both devices run both services, ea…

The difference here is that the integrated device with a screen is a Pi 3B+ and the standalone api is run on a Pi Zero W. They will share 2 of 3 services with the same exact code base. That means I’m forced to do two difference applications, which seems like the best option anyways, but I don’t really want to maintain two separate repositories.

What would work well is if I could somehow maintain two separate docker compose files, one that contains all three services and another that only has two. The second best would probably be if I could optionally start services but it doesn’t seem like that is possible. Being a relative docker noob I wanted to post here and see if you all had any suggestions.

This answer on SO seemed like a good option but I’m not sure how to define the key based on variables or what kind of options we had specifically to Balena.

> <https://stackoverflow.com/questions/37254881/is-there-any-way-to-disable-a-service-in-docker-compose-yml/37255042#37255042>

---

<div class="post-metadata">

**Author:** ![thundron](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/thundron/32/1379_2.png) [@thundron](https://forums.balena.io/u/thundron)\
**Post date:** [October 18, 2019, 9:17pm UTC](https://forums.balena.io/t/selective-docker-compose/37746/7 "2019-10-18T21:17:04Z")

</div>

Hi there, another solution if you have different `Dockerfile.template` for your services is that you could check the device type before running the services you need to include/exclude, something like `if $wrongDeviceType then sleep infinity` so that you can run services based on your needs.

---

<div class="post-metadata">

**Author:** ![thundron](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/thundron/32/1379_2.png) [@thundron](https://forums.balena.io/u/thundron)\
**Post date:** [October 18, 2019, 9:26pm UTC](https://forums.balena.io/t/selective-docker-compose/37746/13 "2019-10-18T21:26:23Z")

</div>

Be wary though that having a sleeping container will still load the container image, thus using the same disk space

---

<div class="post-metadata">

**Author:** ![dt-rush](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/dt-rush/32/1405_2.png) [@dt-rush](https://forums.balena.io/u/dt-rush)\
**Post date:** [October 18, 2019, 9:40pm UTC](https://forums.balena.io/t/selective-docker-compose/37746/14 "2019-10-18T21:40:16Z")

</div>

I’ve just opened a feature request on `balena-cli` for command-line specification of the `docker-compose.yml` file to use [1]. For now, though, we simply use the one file. If you wanted, you could define two files with differing services, and you could write a small script in the repo that you will use to deploy, which copies one or other other of the `docker-compose.yml` files from a subdir into the root, just before running `balena push` or `balena deploy`.

[1] [https://github.com/balena-io/balena-cli/issues/1478](https://github.com/balena-io/balena-cli/issues/1478)

---

<div class="post-metadata">

**Author:** ![dt-rush](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/dt-rush/32/1405_2.png) [@dt-rush](https://forums.balena.io/u/dt-rush)\
**Post date:** [October 18, 2019, 9:40pm UTC](https://forums.balena.io/t/selective-docker-compose/37746/15 "2019-10-18T21:40:48Z")

</div>

This would mean that only the services needed for each device-type/application are build and loaded onto those devices’ disks.

---

<div class="post-metadata">

**Author:** ![dt-rush](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/dt-rush/32/1405_2.png) [@dt-rush](https://forums.balena.io/u/dt-rush)\
**Post date:** [October 18, 2019, 10:04pm UTC](https://forums.balena.io/t/selective-docker-compose/37746/18 "2019-10-18T22:04:19Z")

</div>

The simplest such script would be the one given in this comment on the github issue: [https://github.com/balena-io/balena-cli/issues/1478#issuecomment-543972752](https://github.com/balena-io/balena-cli/issues/1478#issuecomment-543972752)

---

<div class="post-metadata">

**Author:** ![AdamLee](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/adamlee/32/2149_2.png) [@AdamLee](https://forums.balena.io/u/AdamLee)\
**Post date:** [October 18, 2019, 10:04pm UTC](https://forums.balena.io/t/selective-docker-compose/37746/19 "2019-10-18T22:04:37Z")

</div>

I have actually thought about trying to implement something like this with Travis CI so when I push to master it picks up the branch and deploys with one compose to one application and another compose to the other. One reason why I like this approach versus the one @thundron mentioned, as you both have already covered, is that the service isn’t built and downloaded when it isn’t being used.

I guess I just need to start setting up the integration, which is something I’ve thought about doing for a long time just with a single application and simple dockerfile.
