- Home
- >
- DevOps News
- >
- Best Practices for Unlocking AppOps with Terraform – InApps 2022
Best Practices for Unlocking AppOps with Terraform – InApps is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn Best Practices for Unlocking AppOps with Terraform – InApps in today’s post !
Read more about Best Practices for Unlocking AppOps with Terraform – InApps at Wikipedia
You can find content about Best Practices for Unlocking AppOps with Terraform – InApps from the Wikipedia website
Bruno Andrade
Bruno is the CEO of Shipa, a Kubernetes developer platform. Bruno previously held software engineering roles at Juniper Networks, HTBASE, Oracle and IBM.
Efficiently managing, scheduling and controlling Kubernetes clusters is a challenge for many DevOps teams spearheading cloud native and microservices modernization efforts. Terraform has earned its popularity among teams by offering convenient tools that address many of these hurdles, making it possible to create and edit environments straight from the CI/CD pipeline. However, out-of-the-box Terraform lacks the capabilities to help developers deploy and control applications as part of an internal developer platform (IDP). Achieving those capabilities requires one additional ingredient: an AppOps model.
DevOps defines and enforces policies such as security and governance. Developers deploy, manage and support their applications. They can do so across multiple Kubernetes clusters and heterogeneous infrastructure, using a single definition model that isn’t tied to that underlying infrastructure.
Here are a few use cases where the AppOps model can go to work:
Use Case #1: Application Deployment
With Kubernetes, the ability of developers to deploy applications quickly is crucial. Normally, DevOps teams must produce, and painstakingly maintain, Terraform deployment templates to enable that development velocity. However, the Shipa provider for Terraform frees DevOps teams from these burdens, by enabling developers to deploy applications on their own.
The following example creates an application, assigns it a CNAME, and deploys it from an existing Docker image:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | terraform { required_providers { shipa = { version = “0.0.1” source = “shipa.io/terraform/shipa” } } } provider “shipa” {} resource “shipa_app” “app1” { app { name = “terraform-app” teamowner = “dev” framework = “dev-framework” } } resource “shipa_app_env” “env1” { app = “terraform-app” app_env { envs { name = “SHIPA_ENV1” value = “test-1” } } } resource “shipa_app_cname” “cname1” { app = “terraform-app” cname = “test.com” encrypt = true } resource “shipa_app_deploy” “deploy1” { app = “terraform-app” deploy { image = “docker.io/shipasoftware/bulletinboard:1.0” } } |
Importantly, you’ve just done this without the need to learn or maintain complex Kubernetes artifacts.
Developers can also specify and deploy the same application definition without knowing the underlying infrastructure they are using, whether it’s Kubernetes or Linux. The framework applies the defined rules automatically upon application deployment. Developers are able to understand and use this application specification model, directly leveraging Terraform as part of their IDP strategy.
Use Case #2: Defining Policies
Maintaining policies and governance in Kubernetes at scale across many teams and applications is as challenging and complex as it is necessary. Pairing Terraform with a provider makes it possible to rapidly introduce governance rules for role-based access control, resource consumption, registry controls, network policies and more.
In the following code:
- The provisioner defines whether the overall framework will be bound to a Kubernetes cluster or Linux server.
- Security defines the application security scan performed before and after each application deployment, and lists any vulnerabilities that are safe to ignore.
- The app_quota controls how applications are allowed to scale; access controls which teams can deploy applications; Plan controls application memory and CPU consumption limits.
- network_policy defines allowed communications among services for ingress and egress, and makes it possible to let developers define custom network policies for their own applications after deployment.
- Finally, container_policy controls which registries images can be pulled from during application deployment, blocking images from untrusted sources.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 | terraform { required_providers { shipa = { version = “0.0.1” source = “shipa.io/terraform/shipa” } } } provider “shipa” {}
resource “shipa_framework” “prod-framework” { framework { name = “production-services” resources { general { setup { public = false default = false provisioner = kubernetes } security { disable_scan = true scan_platform_layers = false ignore_components = [“apt”, “bash”, “…”] ignore_cves = [“CVE-2020-27350”, “CVE-2011-3374”, “…”] } app_quota { limit = “5” } access { append = [“dev-team”] } plan { name = “production-plan” } network_policy { ingress { policy_mode = “allow-custom-rules-only” custom_rules { id = “rule-name” enabled = true description = “rule description” allowed_apps = [“app1”, “app2”] ports { port = 8080 protocol = “TCP” } } } egress { policy_mode = “allow-all” } disable_app_policies = “false” } container_policy { allowed_hosts = [“docker.io/shipasoftware”, “docker.io/shiparepo”] } } } } } |
Terraform and AppOps now enable your team to quickly define policies and more easily meet application security requirements. Organizations can also pursue DevSecOps goals by replacing complex policies with ones that more users can easily understand and report on.
Use Case #3: Integrate Terraform into Your IDP Strategy
With Terraform enabling your internal developer platform, developers can also continuously manage applications and governance policies, effectively closing the loop between CI/CD and operations. Developers can also integrate applications and alerts into the existing stack — along with application and policy observability — and log and audit report access. Together, these features enable the IDP to provide an end-to-end AppOps model.
The Path to AppOpps Is There for the Taking
Using a provider for Terraform to implement AppOps eliminates template-related overhead. It enables DevOps to efficiently focus on security and governance, and rapidly produce policies. And it empowers developers to deploy and manage applications without assistance via a fully-enabled IDP.
To get more information on the Shipa provider for Terraform, visit learn.shipa.io/docs/terraform.
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
Photo by Harrison Haines from Pexels.
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.
