-
Notifications
You must be signed in to change notification settings - Fork 0
dft street manager spike 0016 azure app services
This ODP describe the design, implementation and learnings from spike STREEWORK-225.
Q: How would we automate the testing & deployment of our apps - ie what are the industry/community-recommended approaches for CICD within this domain?
The easiest way to accomplish the goal would be to use containers. docker compose can be used to spin application with mocks or some part of whole environment.
With docker it is much easier to implement pipelines with any CICD system. Unfortunately, ASE does not allow to run containers.
Q: What might the developer experience and workflow look like? Will developers be able to have full access to investigate and resolve CICD pipeline issues, for example? Will they be able to define and deploy apps to dev environments with zero ops involvement?
It depends if we choose to deploy application source code or docker container.
To deploy source code, we might have to expose "deployment user" credentials to developers. Next step is to add new origin to git repository. To deploy application it is a matter of merging code to master branch and pushing it to the azure remote. nodejs example.
Q: How much of the solution can be covered by IaaC tooling? What gaps are there? What tools/approaches are available to plug those gaps?
Most of the solution might be covered by Terraform. This is well proven tool, which uses DSL. Easy to edit, test and deploy.
Unfortunatelly Azure is not covered by 100%. Ie. deploying application using ASE will require to use ARM templates (fortunatelly you can do that with TF).
The difference in approach between Terraform and ARM templates is huge. In Terraform you declare an object once - any configuration changes will be applied to the same object each time. ARM will create new object each time. Additionally ARM use JSON syntax. This leads to various additional problems we will need to solve ie. how do we validate JSON templates, how do we segregate components, how do we cleanup unused resources?
Q: What would the patching process look like? How could this be achieved without impacting service?
Consider patch as regular change - you need to do new deployment despite the nature of patch.
Q: Are internal services deployed with TLS enabled? If not, is it an option?
Yes.
Q: Is it possible to use acls/security groups to whitelist trusted IPs/ports at the perimeter? eg locking down cluster/apps in dev environments to Kainos IPs only
Yes by using Network Security Groups.
Q: Can the service provide fully automatic auto-scaling (and auto-healing)?
Auto-scaling and Auto-healing is builded in and enabled by default.
Q: How does outbound internet access work, eg for third party API calls? Do outbound calls originate from a fixed IP, to allow IP whitelisting on the remote side?
Each application got 3 own Outbound IP Addresses (ie. 52.176.149.197,52.176.151.243,52.176.149.67,52.173.18.146) - but you can't preserve them.
Q: What technical gaps, limitations or technical challenges were encountered with the technology, tooling or process, during the spike?
- No 100% Terraform coverage for Azure
- ARM templates are hard to generate, maintain and debug
- Building ASE can take up to 2 hours, which limits us in flexibility in terms of environment (re)builds.