So you've done hunderds of #microservices, you're running them in #docker and development,
testing (don't even get me started on deployment) have just got infinitely more sophisticated.
You're keeping all those shiny docker containers in
docker-compose so you can run them locally,
building with your favourite build tool that spits the containers all over the place.
And you either are in a dev mode or production mode. Either all in docker or all in local.
Or you do all that manually. Or start a service in docker to get the dependencies started and then kill the top-level one.
However here's a quick fix to the cumbersome process…
All you need to do is fetch dependencies for given service and start them and run the service(s) under development with incremental build tool with local-dev config.
Makefile for most of the cumbersome automation around projects and interacting with bash environment rather than pushing all too much project unrelated stuff into sbt/lein/mix.
Here's a sample task that does what's described above:
The task simply issues docker-compose and sbt commands for any given project, therfore you can run it as follows:
Which will execute the command for both first-service and second-service in two separate threads allowing the whole thing to work independently.
That's why the whole
.PHONY magic is being used rather than simple variables.
I'm also using a simple utility I have put together in a couple of minutes - dcdeps (as in: docker-compose dependencies).
The utility simply looks into given compose.yml and prints dependencies for given service, hance docker-compose uses that for running all the listed services in the background
with filtering out the services that are about to be ran.
The thing is though, that the approach enables you to simply change the tags of containers and run mocks (prism, json-placeholder, wiremock anyone?) instead of the real thing.