Skip to content

Commit

Permalink
docs(src/applications/inter-app-communication.md) Add first draft
Browse files Browse the repository at this point in the history
Add first draft of inter-app communication.
Apply changes requested by review.
  • Loading branch information
chexxor committed Mar 22, 2017
1 parent 019b7af commit 8980c62
Show file tree
Hide file tree
Showing 2 changed files with 8 additions and 0 deletions.
1 change: 1 addition & 0 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,7 @@ pages:
- Managing App Processes: applications/managing-app-processes.md
- Managing App Configuration: applications/managing-app-configuration.md
- Managing App Lifecycle: applications/managing-app-lifecycle.md
- Inter-app Communication: applications/inter-app-communication.md
- Resource Limits: applications/managing-resource-limits.md
- Domains and Routing: applications/domains-and-routing.md
- SSL Certificates: applications/ssl-certificates.md
Expand Down
7 changes: 7 additions & 0 deletions src/applications/inter-app-communication.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
## Inter-app Communication

A common architecture pattern of multi-process applications is to have one process serve public requests while having multiple other processes supporting the public one to, for example, perform actions on a schedule or process work items from a queue. To implement this system of apps in Deis Workflow, set up the apps to communicate using DNS resolution, as shown above, and hide the supporting processes from public view by removing them from the Deis Workflow router. See [Deis Blog: Private Applications on Workflow](https://deis.com/blog/2016/private-applications-on-deis-workflow/) for more details, which walks through an example of removing an app from the router.

### DNS Service Discovery

Deis Workflow supports deploying a single app composed of a system of processes. Each Deis Workflow app communicates on a single port, so communicating with another Workflow app means finding that app's address and port. All Workflow apps are mapped to port 80 externally, so finding its IP address is the only challenge. Workflow creates a [Kubernetes Service](https://kubernetes.io/docs/user-guide/services/) for each app, which effectively assigns a name and one cluster-internal IP address to an app. The DNS service running in the cluster adds and removes DNS records which point from the app name to its IP address as services are added and removed. Deis Workflow apps, then, can simply send requests to the domain name given to the service, which is "app-name.app-namespace".

0 comments on commit 8980c62

Please sign in to comment.