I’ve successfully deployed my first service on Okteto , which was a smooth experience. However, I’m now faced with a challenge of deploying other services that need to communicate with this initial service.
While I understand the monorepo approach well, thanks to various examples, I’m having difficulty grasping the poly-repo or multi-repo approach. I’m hoping some community members or the Okteto team could shed some light on this and provide patterns for deploying such stacks.
During my research, I found two example repos provide by the Okteto team:
However, it seems like these repos depend on each other, creating what appears to be a circular dependency. Could someone please clarify how this works?
Here is a brief description of some key services in our company, and their dependencies. All services need access to the same Kafka database:
Monolith uses:
Kafka
Authorization service
Billing service
Authorization service uses:
Kafka
Billing service uses:
Authorization service
Monolith
I’d appreciate any advice on how to configure each repo so that all service dependencies are available when a developer needs to work on a particular service.
okteto deploy discovers dependencies defined in an okteto.yaml recursively, but they are not nested inside each other. If the dependency is already scheduled for deployment, it is skipped, effectively stopping any circular flow.
In the examples you linked above, when you deploy okteto/movies-api, it will schedule the deployment of okteto/movies-multi-repo as a dependency which can be observed as follows:
When okteto/movies-multi-repo starts deploying, it will ensure that both okteto/movies-frontend and okteto/movies-api are deployed as dependencies. Since okteto/movies-api is already scheduled for deployment, it is skipped.
Finally, okteto/movies-frontend has okteto/movies-multi-repo as a dependency in the same way as okteto/movies-api. As it was already deployed from the step above, it is again skipped.
Also, please note that dependency declaration in the okteto.yaml manifest has an extended notation where you can customize branches, environment variables, and more. Here is an anchor link to the Okteto Manifest docs:
I read the Development environments in the cloud - monday Engineering post on how they use Okteto. Very cool article. In their post they use Okteto pipelines and Okteto stacks. I’m not sure but it seems this functionality can now all be included in a single okteto.yaml file right?
Nevermind. I just found the answer on this in the documentation:
Previously, developers would have to run a series of commands, such as okteto pipeline deploy or okteto stack deploy and then okteto up . The choice between using either the pipeline or stack commands was often a tripping point for our users and introduced needless complexity.
, which was a smooth experience. However, I’m now faced with a challenge of deploying other services that need to communicate with this initial service.
