semvec/pypi-packages huggingface dataset:
cloudicorn-azurerm 0.10
Taking Infrastructure As Code to the next level
License: MIT

# cloudicorn_azurerm

Installs addons for handling azurerm backend components.

# setting up credentials

Once you have [installed and authenticated](https://github.com/jumidev/cloudicorn-cli/blob/master/https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) to your azure cli, create a service principal following [these instructions](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/service_principal_client_secret)

You will get a result something like this:

```
{
  "appId": "00000000-0000-0000-0000-000000000000",
  "displayName": "azure-cli-2017-06-05-10-41-15",
  "name": "http://azure-cli-2017-06-05-10-41-15",
  "password": "0000-0000-0000-0000-000000000000",
  "tenant": "00000000-0000-0000-0000-000000000000"
}
```

Save them to environment variables (see `.envrc.tpl`)

|  value  | env var |
| ------- | ----------------|  
| `appId` | `AZURE_CLIENT_ID` |
| `password` | `AZURE_CLIENT_SECRET` |
| `tenant` | `AZURE_TENANT_ID` |

You'll also need to set `AZURE_SUBSCRIPTION_ID`

## running tests

Create a storage account and container that the above service principal can write to 

`make test` Uses terraform modules in `https://github.com/jumidev/cloudicorn-testmodules-azure`

- runs a set of components

## testing with opentofu instead of terraform

opentofu can now be used as a drop in replacement for terraform and can be tested independently of terraform.  You'll need to enable the opentofu extension in the test virtual env by running. `make enable_opentofu`

Be sure to also run `cloudicorn_setup` and install opentofu from the main menu.  Confirm this extension is installed by running `make setup`.  You should see a message at the bottom 

```
opentofu installed and up to date
```

Once it is installed, run `make test` as you would normally
cloudicorn-aws 0.10
AWS Specific extension for cloudicorn-cli
License: MIT

# cloudicorn_aws

Installs addons for handling aws backend components.

# setting up credentials

Once you have [installed and authenticated](https://github.com/jumidev/cloudicorn-cli/blob/master/https://aws.amazon.com/cli/) to your aws cli, grab your credentials and save them to environemnt vars  (see `.envrc.tpl`)

## running tests

Create an s3 bucket above aws account can write to 

`make test` Uses terraform modules in `https://github.com/jumidev/cloudicorn-testmodules-aws`

- runs a set of components

## testing with opentofu instead of terraform

opentofu can now be used as a drop in replacement for terraform and can be tested independently of terraform.  You'll need to enable the opentofu extension in the test virtual env by running. `make enable_opentofu`

Be sure to also run `cloudicorn_setup` and install opentofu from the main menu.  Confirm this extension is installed by running `make setup`.  You should see a message at the bottom 

```
opentofu installed and up to date
```

Once it is installed, run `make test` as you would normally
cloudicorn-cli 0.10
Taking Infrastructure As Code to the next level
License: MIT
Keywords: build_date:2024-11-28

# Here's the deal:

Managing Cloud infrastructure is **`Difficult`**, **`Messy`** and **`Volatile.`**

**`Difficult`** because it requires a broad spectrum of skills ranging from programming to systems to networking and troubleshooting. \
**`Messy`** because infrastructure has to reconcile multiple, sometimes conflicting constraints.  Technical constraints, cost constraints, regulatory and vendor constraints, security constraints, client-imposed constraints.... you get the idea.\
**`Volatile`**  Because your infrastructure is always growing.  Because small infrastructure changes can sometimes have unexpected impacts.

# What IAC Should Be

- **Your infrastructure is never perfect.**  There are always special cases, cost / benefit compromises, legacy systems, temporary workarounds, long migrations and surprises.  IAC should not get in the of way implementing these specificities, rather it should enable colleagues with all skillsets to document them clearly, easily understand how the pieces fit together, and have a clear vision of future changes.
- Infra as code **should be plain and simple**.  It should not add unneccessary burden to developers, it should be accessible to other stakeholders such as architects, support, cyber security and monitoring teams.
- Infra as code **should be business process oriented**.  Every organization has teams with dedicated processes to ensure application availability.  IAC should be more than an opaque collection of technical configuration, but rather integrate with and reinforce these business processes.

# The cloudicorn approach

- Using Cloudicorn, cloud assets are grouped into functional units called `components.`  Unlike terraform resources whose interdependencies are **technical**, components are **functional**.  Anyone with a basic understanding of cloud assets can understand what a component is without having to master the technical specifics.
- Cloudicorn projects are searchable and auditable.  Determining which business processes are impacted by a given change is straighforward.
- Cloudicorn ships with pre-coded components for major cloud providers designed to fit most use cases.  You can of course [write your own components!](https://github.com/jumidev/cloudicorn-cli/blob/master/docs/component_guidelines.md)

There's more to it than that, but that's the idea.  Thanks for making it this far.  If you're interested in learning more about cloudicorn:

- [Getting Started](https://github.com/jumidev/cloudicorn-cli/blob/master/docs/)
- [Installation](https://github.com/jumidev/cloudicorn-cli/blob/master/docs/installation.md)
- [Core concepts](https://github.com/jumidev/cloudicorn-cli/blob/master/docs/core_concepts.md)