To deploy an application in your service interconnection fabric, you will need access to the fabric manager and the policy orchestrator.
This tutorial will take approximately 10 minutes to complete.
To generate a new authorization token for your application service, run this
service_name@contract_name–in this example
http-proxy@myapp as an argument:
]$ bwctl-api create service_token [email protected]
You should see output similar to this:
--- apiVersion: policy.bayware.io/v1 kind: ServiceToken metadata: token_ident: 00c1babd-3197-465a-beec-6d144e53d4ef:46a55e4963263260c3d61eb4b4b67882 spec: domain: myapp expiry_time: 30 Sep 2020 18:41:52 GMT service: http-proxy status: Active
Token comprises two parts–token identity and token secret–separated by a colon. This is the only time you can see the token secret. Be sure to copy the entire TOKEN as it appears on your screen, it will be needed later.
SSH to Workload Node¶
To deploy the service on the workload node, first ssh to the workload node from your fabric manager as such:
]$ ssh azr2-w01-myfab2
SSH service is set up automatically for easy and secure access to workload nodes in your service interconnection fabric.
When you are on the workload node, switch to root level access:
[[email protected]]$ sudo su -
Next, edit the policy agent token file by running this command:
]# nano /opt/bayware/ib-agent/conf/tokens.dat
Add the token to the
tokens.dat file and save the file, which in this example will contain after editing:
To apply the token, reload the policy agent by running this command:
]# systemctl reload ib-agent
At this point, you can visit the policy orchestrator and find a registered endpoint on the Service Graph page of your application.
Now, you can install your application service on this workload node. In this
example, a package called
getaway-proxy installs by running the command:
]# apt-get install getaway-proxy
The service automatically discovers all remote services sharing the same contract. So, edit the application service configuration file to update the remote service URL, by running this command:
]# nano /opt/getaway-proxy/conf/app.conf
After editing, the service configuration file in this example contains:
WS_APP = 'http://responder.frontend.myapp.ib.loc:8080/'
The FQDN part of remote service URL is automatically built in such a manner: <role>.<contract>.<domain>.ib.loc
Finally, to start the application service, run this command:
]# systemctl start getaway-proxy
You have successfully installed the application service on the workload node in your service interconnection fabric.
Your application policy for this service is infrastructure-agnostic and allows the service to access only particular security segment. You can move this service across workload nodes in multiple clouds and the security segment will expand or shrink automatically.
The service will automatically discover the opposite-role services in its security segment as those services will go up or down across multiple clouds.