<commit_before># cf-deployment

**This repo is under initial development.
When we're more confident
that we've achieved initial stability,
this warning will be removed,
and version tagging will be added.
We'd love for members of the CF community
to try cf-deployment and give us feedback.
Github issues welcome.
Find us on the #cf-deployment channel in the cloudfoundry Slack.**


### Table of Contents
* <a href='#purpose'>Purpose</a>
* <a href='#usage'>Usage</a>
* <a href='#contributing'>Contributing</a>
* <a href='#setup'>Setup and Prerequisites</a>
* <a href='#deploying'>Deploying `cf-deployment`</a>
* <a href='#ops-files'>Ops Files</a>
* <a href='#ci'>CI</a>

## <a name='purpose'></a>Purpose
This repo contains a canonical manifest
for deploying Cloud Foundry without the use of `cf-release`,
relying instead on individual component releases.
It will replace the [manifest generation scripts in cf-release][cf-release-url]
when `cf-release` is deprecated.
It uses several newer features
of the BOSH director and CLI.
Older directors may need to be upgraded
and have their configurations extended
in order to support `cf-deployment`.

`cf-deployment` embodies several opinions
about Cloud Foundry deployment.
It:

- prioritizes readability and meaning to a human operator.
  For instance, only necessary configuration is included.
- emphasizes security and production-readiness by default.
  - bosh's `--vars-store` feature is used
  to generate strong passwords, certs, and keys.
  There are no default credentials, even in bosh-lite.
  - TLS/SSL features are enabled on every job which supports TLS.
- uses three AZs, of which two are used to provide redundancy for most instance groups.
The third is used only for instance groups
that should not have even instance counts,
such as etcd and consul.
- uses Diego natively,
does not support DEAs,
and enables diego-specific features
such as ssh access to apps by default.
- deploys jobs to handle platform data persistence
using the cf-mysql release for databases
and the CAPI release's WebDAV job for blob storage.
- assumes load-balancing will be handled by the IaaS
or an external deployment.
- assumes GCP as the default deployment environment.
For use with other IaaSs, see the **Ops Files** section below.

## <a name='usage'></a>Usage
To deploy to a configured BOSH director using the new `bosh` CLI:

```
export SYSTEM_DOMAIN=some-domain.that.you.have
bosh -e my-env -d cf deploy cf-deployment/cf-deployment.yml \
  --vars-store env-repo/deployment-vars.yml \
  -v system_domain=$SYSTEM_DOMAIN \
  [ -o operations/CUSTOMIZATION1 ] [ -o operations/CUSTOMIZATION2 (etc.) ]
```

The CF Admin credentials will be stored in the file passed to the `--vars-store` flag
(`env-repo/deployment.yml` in the example).
You can find them by searching for `uaa_scim_users_admin_password`.

See the rest of this document for more on the new CLI, deployment vars, and configuring your BOSH director.

## <a name='contributing'></a>Contributing
Although the default branch for the repository is `master`,
we ask that all pull requests be made against
the `develop` branch.
Please also take a look at the ["style guide"](texts/style-guide.md),
which lays out some guidelines for adding properties or jobs
to the deployment manifest.

We ask that pull requests and other changes be successfully deployed,<commit_msg>Add a note describing the readiness of cf-deployment<commit_after># cf-deployment

**This repo is under initial development.
When we're more confident
that we've achieved initial stability,
this warning will be removed,
and version tagging will be added.
We'd love for members of the CF community
to try cf-deployment and give us feedback.
Github issues welcome.
Find us on the #cf-deployment channel in the cloudfoundry Slack.**


### Table of Contents
* <a href='#purpose'>Purpose</a>
* <a href='#readiness'>Is `cf-deployment` ready to use?</a>
* <a href='#usage'>Usage</a>
* <a href='#contributing'>Contributing</a>
* <a href='#setup'>Setup and Prerequisites</a>
* <a href='#deploying'>Deploying `cf-deployment`</a>
* <a href='#ops-files'>Ops Files</a>
* <a href='#ci'>CI</a>

## <a name='purpose'></a>Purpose
This repo contains a canonical manifest
for deploying Cloud Foundry without the use of `cf-release`,
relying instead on individual component releases.
It will replace the [manifest generation scripts in cf-release][cf-release-url]
when `cf-release` is deprecated.
It uses several newer features
of the BOSH director and CLI.
Older directors may need to be upgraded
and have their configurations extended
in order to support `cf-deployment`.

`cf-deployment` embodies several opinions
about Cloud Foundry deployment.
It:
- prioritizes readability and meaning to a human operator.
  For instance, only necessary configuration is included.
- emphasizes security and production-readiness by default.
  - bosh's `--vars-store` feature is used
  to generate strong passwords, certs, and keys.
  There are no default credentials, even in bosh-lite.
  - TLS/SSL features are enabled on every job which supports TLS.
- uses three AZs, of which two are used to provide redundancy for most instance groups.
The third is used only for instance groups
that should not have even instance counts,
such as etcd and consul.
- uses Diego natively,
does not support DEAs,
and enables diego-specific features
such as ssh access to apps by default.
- deploys jobs to handle platform data persistence
using the cf-mysql release for databases
and the CAPI release's WebDAV job for blob storage.
- assumes load-balancing will be handled by the IaaS
or an external deployment.
- assumes GCP as the default deployment environment.
For use with other IaaSs, see the **Ops Files** section below.

### <a name='readiness'></a> Is `cf-deployment` ready to use?
We've been testing cf-deployment for some time,
and many of the development teams in the Cloud Foundry organization
are using it for development and testing.
If that describes your use case,
you can use cf-deployment as your manifest.

**Migrating from cf-release:**
The Release Integration team is still working on developing
a migration path from cf-release.
This use case is not sufficiently tested yet,
and we don't advise anybody to attempt it
until we develop the necessary tooling and guide.

## <a name='usage'></a>Usage
To deploy to a configured BOSH director using the new `bosh` CLI:

```
export SYSTEM_DOMAIN=some-domain.that.you.have
bosh -e my-env -d cf deploy cf-deployment/cf-deployment.yml \
  --vars-store env-repo/deployment-vars.yml \
  -v system_domain=$SYSTEM_DOMAIN \
  [ -o operations/CUSTOMIZATION1 ] [ -o operations/CUSTOMIZATION2 (etc.) ]
```

The CF Admin credentials will be stored in the file passed to the `--vars-store` flag
(`env-repo/deployment.yml` in the example).
You can find them by searching for `uaa_scim_users_admin_password`.

See the rest of this document for more on the new CLI, deployment vars, and configuring your BOSH director.

## <a name='contributing'></a>Contributing
Although the default branch for the repository is `master`,
we ask that all pull requests be made against
the `develop` branch.
Please also take a look at the ["style guide"](texts/style-guide.md),
which lays out some guidelines for adding properties or jobs
to the deployment manifest.

We ask that pull requests and other changes be successfully deployed,
{'fraction_non_alphanumeric': 0.08367181153533712, 'fraction_numerical': 0.0005415651232060655, 'mean_word_length': 4.596212121212122, 'pattern_counts': {'":': 0, '<': 47, '<?xml version=': 0, '>': 47, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '845307', 'n_tokens_mistral': 2136, 'n_tokens_neox': 2045, 'n_words': 982}