Docker, microservices and git workflow

Question

We are a young company that's developing a web app in node.js with the microservice architecture.

Actual development workflow:

1. Each microservice is stored in a private repository
2. Different developers/teams can access to specific repositories (microservices)
3. Each developer can work locally using docker. He must pull a docker "development environment image" that includes all microservices pulled from bitbucket. He can maps his local microservice source path into docker container as volume and start to develop.

The problem: each developer can see all microservices sources passing through the docker container. A developer that can work/access only to "Microservice1" should not see the sources of "Microservice2." If I want to assume an external freelancer develops a microservice I do not want to show him the whole system sources as these might contain valuable intellectual property.

Solutions?

Answer 1

It sounds like your problem is you are putting all your microservices into the same "development environment image" as you describe. So any service container can see all others.

What you should be doing is building specific docker images for each microservice, building on a base image docker that contains the appropriate defaults as well as each specific microservice.

New services can be developed from this base image. Because the base image contains none of the other services, you don't have to worry about your problem at all.

You may even want server / client images for each (your question isn't detailed enough to really answer whether this is important or not). Given that you are asking about an external contractor, this might be helpful too - but will depend on how your microservices actually work.

One of the huge advantages of docker is the ability to do this sort of thing. Making a single "everything we run uses the same docker image" kind of misses the point of docker.

Answer 2

If you don't trust someone with your code, you shouldn't send your code to their machine. Period.

Docker has made quite a few improvements to networking in the latest few releases. If you architect your system to have one container per microservice, you should be able to have development environments talk to a remote server, and production and test environments all on the same host, and from the microservice's point of view inside the container, the only difference is some extra latency.

You could probably add this incrementally, if you want to have "trusted" and "untrusted" tiers of developers. However, like enderland pointed out, you're kind of missing the point of docker by using only one container. Using multiple containers makes it easier to do things like upgrade, backup, or restart individual services. Development is typically more rapid because you can isolate your individual service more easily. Each service only has to agree on an interface, not other internal details.

Lots of times you don't even need the rest of the system to be available in order to test a microservice. You can just start its own container and bang on it with curl, postman, or automated test scripts. You can provide mock development environments that are both easier for developers to work with and don't contain proprietary information.

It may feel more difficult now to split into separate containers, but it will be worth it in the long run.