{"id":5002,"date":"2020-10-05T13:44:37","date_gmt":"2020-10-05T12:44:37","guid":{"rendered":"https:\/\/rakhesh.com\/?p=5002"},"modified":"2020-10-05T19:01:31","modified_gmt":"2020-10-05T18:01:31","slug":"til-a-good-use-case-for-docker-compose","status":"publish","type":"post","link":"https:\/\/rakhesh.com\/docker\/til-a-good-use-case-for-docker-compose\/","title":{"rendered":"[TIL] A good use case for Docker Compose"},"content":{"rendered":"

I am sure it’s not a new discovery, but it was new to me and considering I had whined about it in the past I thought I’d set the record straight. In a previous post, while discovering Docker, I had complained about Docker compose files and how I’d rather just use the docker run<\/code> command to setup things (hmm<\/em>, not sure if I actually said the latter or it was more of an implied thing). Since then I had created a bunch of shell scripts for each of the containers I was impelementing as a way of quickly recreating them with the correct volumes, IP addresses, etc. I had single containers anyways and nothing complex that might require orchestration and Docker Compose.<\/p>\n

Last week however I chanced upon a video<\/a> between Scott Hanselman and Chad Metcalf wherein Chad casually mentioned that he uses Docker Compose, even though he has a single container<\/em>, as that way he can capture all the settings etc. of the container. That was a light-bulb moment for me. Yes, that makes way better sense than having shell scripts to create containers… so since then I have been re-visiting Docker Compose. I made the following for my kea-knot<\/a> container:<\/p>\n

version: \"3.8\"\r\n\r\nservices:\r\n    kea-knot:\r\n        image: rakheshster\/kea-knot:1.8.0-2.9.5-3\r\n        container_name: kea-knot\r\n        networks:\r\n            my_macvlan_network:\r\n                ipv4_address: 192.168.17.21\r\n        volumes:\r\n            - \"kea-knot_knotconfig:\/etc\/knot\"\r\n            - \"kea-knot_knotzones:\/var\/lib\/knot\/zones\"\r\n            - \"kea-knot_keaconfig:\/etc\/kea\"\r\n            - \"kea-knot_kealeases:\/var\/lib\/kea\"\r\n        environment:\r\n            - \"TZ=Europe\/London\"\r\n        restart: unless-stopped\r\n        cap_add:\r\n            - NET_ADMIN\r\n\r\nnetworks:\r\n    # The network is created outside of Docker Compose and don't attempt to create it\r\n    my_macvlan_network:\r\n        external: true\r\n        name: my_macvlan_network\r\n\r\n# I specify the volume name again via \"name\" so that compose creates the volume with that name\r\n# If I don't do this the volume name before <projectname or foldername>-<the volume name below>. Example: docker-kea-knot_kea-knot_knotconfig\r\nvolumes:\r\n    kea-knot_knotconfig:\r\n        name: kea-knot_knotconfig\r\n    kea-knot_knotzones:\r\n        name: kea-knot_knotzones\r\n    kea-knot_keaconfig:\r\n        name: kea-knot_keaconfig\r\n    kea-knot_kealeases:\r\n        name: kea-knot_kealeases\r\n<\/pre>\n
Nothing fancy but I found the solution to one of my previous issues – that of networks and volumes having the project name prefixed to it automatically, along with how to deal with macvlan networks correctly (version 3.x of Compose does not support specifiying gateway<\/a> & IP range when you define the network) – through a bit of Googling today. Turns out since I create the macvlan network separately anyways, I can just define it as an external<\/code> network and thus Docker Compose won’t bother with it. And to prevent Docker Compose from prefixing the project or folder name for volumes, I can add a name<\/code> property.<\/p>\n
I think I will start using Docker Compose files a bit more over shell scripts.<\/p>\n","protected":false},"excerpt":{"rendered":"
I am sure it’s not a new discovery, but it was new to me and considering I had whined about it in the past I thought I’d set the record straight. In a previous post, while discovering Docker, I had complained about Docker compose files and how I’d rather just use the docker run command … Continue reading [TIL] A good use case for Docker Compose<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[912],"tags":[],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/5002"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=5002"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/5002\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=5002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=5002"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=5002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}