5

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?

0

2 Answers 2

6

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.

1
  • The problem of docker images is that all files inside a container could be easily access with docker CP command for example... Mar 1, 2016 at 18:03
3

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.

1
  • Actually we have another implementation with one service for one container, and we are using docker-compose to links microservices together, it is a good choise. The problem of remote approach is: 1) DEV1 is developing MS1 on localhost in a docker container 2) MS1 links to MS2,MS3 that are on remote sandbox 3) MS2 links to MS1 The problem is in the step3, becouse MS2 call MS1, but REMOTE version of MS1, not local. Mar 2, 2016 at 8:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.