From 28679691310c25d4a86cd65db52e41c2ba692ef0 Mon Sep 17 00:00:00 2001 From: Sergey Shurlakov Date: Mon, 4 Oct 2021 21:54:06 +0600 Subject: [PATCH] Minor changes and fixed typos (#124) Co-authored-by: Sergey Shurlakov --- docs/en/Control_scripts.md | 2 +- docs/en/Helm-based_deployment_guide.md | 4 ++-- docs/en/Integration.md | 2 +- docs/en/Octopod_deployment_guide.md | 6 +++--- docs/en/Overview.md | 2 +- docs/en/PM_case_study.md | 2 +- docs/en/README.md | 2 +- docs/en/Security_model.md | 4 ++-- docs/en/Tech_case_study.md | 2 +- docs/en/Technical_architecture.md | 2 +- 10 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/en/Control_scripts.md b/docs/en/Control_scripts.md index 5154286..d67a23e 100644 --- a/docs/en/Control_scripts.md +++ b/docs/en/Control_scripts.md @@ -11,7 +11,7 @@ Control scripts can be roughly split into two categories: (1) control scripts in _stdout_ and _stderr_ output from the most important scripts involved in the deployment lifecycle will be collected and stored. DevOps engineers can then view these logs from the _octo CLI_, should that be needed. -All of the _scripts_ in this category receive the exact same exact same set of command line arguments. +All of the _scripts_ in this category receive the exact same set of command line arguments. There are four "static" arguments that are passed to all *scripts* in this category. The first three arguments come from the [_Kubernetes ConfigMap_][configmap]: * `--project-name` – the name of the project. It is supplied mostly for informational purposes and can be useful for sending notifications if that is necessary. diff --git a/docs/en/Helm-based_deployment_guide.md b/docs/en/Helm-based_deployment_guide.md index 7a40166..1f7337b 100644 --- a/docs/en/Helm-based_deployment_guide.md +++ b/docs/en/Helm-based_deployment_guide.md @@ -49,7 +49,7 @@ So here you have it, your first Octopod deployment! ## Going further -As we can said earlier you can override all default parameters using Octopod UI. Let's dive right in! +As we said earlier you can override all default parameters using Octopod UI. Let's dive right in! First, let's archive our wordpress deployment: @@ -85,6 +85,6 @@ As in the previous example Octopod parsed the _App Overrides_ from the [chart va `chart_repo_url`, `chart_name` parameters are usually provided by the chart developer. Version however is usually skipped and you encouraged to take the last one, but we think about this as a bad practice. -If you not sure where to get the `chart_version` parameter you can add repo locally using `helm repo add` and then execute `helm search repo -l` too see the whole list of available chart versions. +If you're not sure where to get the `chart_version` parameter you can add repo locally using `helm repo add` and then execute `helm search repo -l` too see the whole list of available chart versions. Now you have Octopod inside Octopod! Try to install your own chart with Octopod! diff --git a/docs/en/Integration.md b/docs/en/Integration.md index 9f5dd03..d88af55 100644 --- a/docs/en/Integration.md +++ b/docs/en/Integration.md @@ -21,7 +21,7 @@ octo create -n $NAME -t $IMAGE_TAG ## πŸš€ Updating deployments -Updating deployments is done using the same arguments, but you need to call `create` command, instead of the `update` command: +Updating deployments is done using the same arguments, but you need to call the `create` command, instead of the `update` command: ```bash octo update -n $NAME -t $IMAGE_TAG diff --git a/docs/en/Octopod_deployment_guide.md b/docs/en/Octopod_deployment_guide.md index dc62fc9..c027d68 100644 --- a/docs/en/Octopod_deployment_guide.md +++ b/docs/en/Octopod_deployment_guide.md @@ -1,10 +1,10 @@ # Octopod Server deployment guide ## Installation options -There are several options to install octopod depending on your needs. +There are several options to install Octopod depending on your needs. -### If you have a kubernetes cluster -You can install octopod in any kubernetes cluster using our [Helm chart](../../charts/octopod). +### If you have a Kubernetes cluster +You can install Octopod in any Kubernetes cluster using our [Helm chart](../../charts/octopod). Your cluster must satisfy following requirements: diff --git a/docs/en/Overview.md b/docs/en/Overview.md index d21a2b5..f5b1e07 100644 --- a/docs/en/Overview.md +++ b/docs/en/Overview.md @@ -8,7 +8,7 @@ _Octopod_ is a tool which implements the multi-staging deployment model (MSDM) o _Octopod_ exists to reduce the overhead in deploying and maintaining per-feature staging environments. This responsibility may otherwise fall to: -1. **DevOps engineers** – this might seem natural since deploying and updating systems in new environments is typically the task of a DevOps engineer who has experience in system administration. However, developers and QA engineers would be blocked for additional periods while DevOps engineers deal with the additional load. +1. **DevOps engineers** – this might seem natural since deploying and updating systems in new environments is typically the task of a DevOps engineer who has experience in system administration. However, developers and QA engineers would be blocked for extended periods while DevOps engineers deal with the additional load. 2. **Developers** – they might take on the responsibility for deploying and maintaining their feature stagings ― this would most likely waste a lot of time since developers might not have the required experience. The process of deploying and updating stagings is likely to be extremely similar across different developed features ― changing the behavior of a button and updating pricing calculations would probably be identical from the point of view of system administration ― a new version of the system needs to be deployed with the same default configuration (the staging configuration, as opposed to a production configuration). diff --git a/docs/en/PM_case_study.md b/docs/en/PM_case_study.md index 07ff6b7..52aa1cf 100644 --- a/docs/en/PM_case_study.md +++ b/docs/en/PM_case_study.md @@ -56,7 +56,7 @@ guarantee that the feature won’t unexpectedly break someone else’s code. If a critical part of the application, like authentication, gets broken, this may block the testing process completely until the problem is resolved. And to top it off, when this happens, it might not be -immediately clear who’s change is to blame. Thus, everyone who did +immediately clear whose change is to blame. Thus, everyone who did recent merges begin looking into their code trying to see whether it was their check-in that broke the server. Of course, it takes time and blocks the development process as well until the culprit merge is found diff --git a/docs/en/README.md b/docs/en/README.md index 62b4da7..cd3b6f5 100644 --- a/docs/en/README.md +++ b/docs/en/README.md @@ -7,7 +7,7 @@ ## πŸ› οΈ Technical documentation - [πŸ— Technical architecture](Technical_architecture.md) -- [βš™οΈ Control script guide](Control_scripts.md) +- [βš™οΈ Control scripts guide](Control_scripts.md) - [πŸ”§πŸ™ Octopod deployment guide](Octopod_deployment_guide.md) - [πŸ”§πŸš€ Helm-based Octopod project setup](Helm-based_deployment_guide.md) - [πŸ™πŸŽ› octo CLI user guide](Octo_user_guide.md) diff --git a/docs/en/Security_model.md b/docs/en/Security_model.md index 805787e..561c4fb 100644 --- a/docs/en/Security_model.md +++ b/docs/en/Security_model.md @@ -22,7 +22,7 @@ There is currently no way to give someone access to _octo CLI_ without giving th _Octopod Server_ is deployed in the `octopod` _Kubernetes_ namespace. Deployments are deployed in the `deployments` namespace. _Octopod Server_ uses the `octopod` [_Service Account_][kubernetes-service-account]. -Octopod needs sufficient permissions to run helm inside kubernetes and create all resources described in helm chart it is installing. Thus permissions are quite extensive. +Octopod needs sufficient permissions to run Helm inside Kubernetes and create all resources described in the Helm chart it is installing. Thus permissions are quite extensive. [RBAC][kubernetes-rbac] rules to describe permissions needed are added automatically by [the Octopod Helm Chart](../../charts/octopod/templates/rbac.yaml). @@ -36,7 +36,7 @@ The [_Web UI_](Technical_architecture.md#-web-ui) on its own does not have any a ## octo CLI authentication -Authentication between _octo CLI_ and _Octopod Server_ is done through special token which is generated automatically or specified by user in `octopod.cliAuthSecret` parameter, as described [here](../../charts/octopod/README.md#parameters) +Authentication between _octo CLI_ and _Octopod Server_ is done through special token which is generated automatically or specified by user in `octopod.cliAuthSecret` parameter, as described [here](../../charts/octopod/README.md#parameters). [kubernetes-service-account]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account [kubernetes-ingress-nginx-external-auth]: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#external-authentication diff --git a/docs/en/Tech_case_study.md b/docs/en/Tech_case_study.md index 5659a37..728e9a1 100644 --- a/docs/en/Tech_case_study.md +++ b/docs/en/Tech_case_study.md @@ -22,7 +22,7 @@ It is sometimes the case that certain features need a "special" environment to b "Current" is used here to denote features that have been completed after the last time QA engineers had the opportunity to test the staging of the given project. It is assumed that the completed features are merged into something analogous to a `master` branch in git. -A way to mitigate the issue might be to have fine-grained control over what features are allowed to be merged into the `master` branch so that when we deploy it, we will have only the one feature which needs the "special" environment, in a sense, batching features based on the environment they require. The main problem with this is that the payment processor is in all likelihood a tiny sliver, a single dimension of the whole space of possible environment setups. Trying to capture and institutionalize the whole breadth of a production environment in your development workflow seems like a futile endeavor. +A way to mitigate the issue might be to have fine-grained control over what features are allowed to be merged into the `master` branch so that when we deploy it, we will have only the feature which needs the "special" environment, in a sense, batching features based on the environment they require. The main problem with this is that the payment processor is in all likelihood a tiny sliver, a single dimension of the whole space of possible environment setups. Trying to capture and institutionalize the whole breadth of a production environment in your development workflow seems like a futile endeavor. Having per-feature stagings allow you to have completely separate and independent configurations for every single feature you develop and test at no additional cost. diff --git a/docs/en/Technical_architecture.md b/docs/en/Technical_architecture.md index e37e142..f08759d 100644 --- a/docs/en/Technical_architecture.md +++ b/docs/en/Technical_architecture.md @@ -51,7 +51,7 @@ This is necessary to make _Octopod_ itself independent from any particular deplo When the [_Octopod Server_](#-octopod-server) _Pod_ starts, the contents of the *control scripts* container are copied into the _Octopod Server_ container file system. This means that the executables need to be either statically linked or interpreted through _Bash_ since it needs to be executed in the _Octopod Server_ container environment. -These [scripts need to be implemented](Control_scripts.md) to deploy _Octopod_. +These [scripts need to be implemented](Control_scripts.md) to deploy _Octopod_ unless the set of generic scripts is used. ### Kube API Server