-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated getting started doc to include section for using existing resources. #200
Conversation
|
||
The pre-created resources must follow the current naming convention. | ||
|
||
| Resource | naming convention | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add more detailed description for each resource features. the keyvault expect a group of secrets with specific names.
The state storage account and the backup state storage accounts are only needed for terraform. They also need to have a container with specific name as well.
The container registry stores the sample app 'eshop on web' api, and web images. Those needs to be created based on a certain commid Id from the eshop repo
symphony/scripts/install/provision.sh
Line 319 in c60ab3a
az acr build --image "${APP_WEB_NAME}:${APP_COMMIT}" --registry "${CR_NAME}" --resource-group "${RG_NAME}" --file "${APP_WEB_DOCKERFILE}" . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When running Symphony provision with pre-created resources like a keyvault, it won't create the keyvault but I'm sure it will still make the secrets. Same for the other resources. The containers will be created for the storage accounts and the images will be pushed to the pre-created ACR. I can double check though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@malcmiller - Even if symphony provision can create those secrets, part of "bring your own" dependencies is allowing users to skip provision entirely. We need to document everything that needs to be done in lieu of symphony provision and that includes setting up secrets and service principals.
|
||
The pre-created resources must follow the current naming convention. | ||
|
||
| Resource | naming convention | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@malcmiller - Even if symphony provision can create those secrets, part of "bring your own" dependencies is allowing users to skip provision entirely. We need to document everything that needs to be done in lieu of symphony provision and that includes setting up secrets and service principals.
|
||
| Name | description | | ||
| ----------------------------- | ------------------- | | ||
| stateStorageAccount | name of the storage account that contains the tfstate | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please add a note here that those secrets (stateStorageAccount, stateStorageAccountBackup, stateContainer, and stateRg) are needed only if you provision Symphony for terraform.
| readerClientSecret | reader service principal client id | | ||
| readerSubscriptionId | reader service principal client id | | ||
| readerTenantId | reader service principal client id | | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add a section about the service principals. The owner service principal is the one used to access the env subscription on which resources will be deployed. While the reader service principal is used to create GH Secret or Azure DevOps service connection to access the Symphony Key vault. The reader Service principal needs to have policy permissions to (get list backup restore) the vault secrets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes. I would also request that you add a section on creating service principals (reader and owner) and include az cli commands to do so.
Also, it should be documented that the reader sp needs an access policy to read secrets from a kv.
|
||
## Using Existing Resources | ||
|
||
Existing resources can be used with Symphony. The resources, however will need to follow a specific naming convention. To use existing resources you will need to create a `symphony.json` in a top level `.symphony` folder. A prefix and suffix value is required. Below is an basic example of that file: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also add a note that instead of using symphony provision a user can use existing resources, basically making it clear that this replaces the need to run symphony provision
|
||
When using an existing State Storage Account or Backup State Storage Account, a container name tfstate must be present. | ||
|
||
### Existing Container Registry |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would leave a note here that ACR is only needed for the canonical application that we ship and is not part of symphony core itself.
Decided not to merge |
Updated getting started doc
close #171