From 0466076968aaa90392d499701b5372c4bf0b462d Mon Sep 17 00:00:00 2001 From: xiaoxiangxianzi Date: Thu, 28 Mar 2024 00:07:19 +0800 Subject: [PATCH] chore: fix some comments Signed-off-by: xiaoxiangxianzi --- 2022/ja/Days/day36.md | 2 +- 2022/ja/Days/day56.md | 2 +- 2022/ja/Days/day68.md | 2 +- 2022/pl/day56.md | 2 +- 2022/pl/day68.md | 2 +- 2022/zh_cn/Days/day56.md | 2 +- 2022/zh_cn/Days/day68.md | 2 +- 2022/zh_tw/Days/day36.md | 2 +- 2022/zh_tw/Days/day56.md | 2 +- 2022/zh_tw/Days/day68.md | 2 +- 2023/day58.md | 2 +- 2023/day81.md | 2 +- 2024/day11.md | 2 +- 2024/day16.md | 6 +++--- 2024/day27.md | 4 ++-- publishing.md | 2 +- 16 files changed, 19 insertions(+), 19 deletions(-) diff --git a/2022/ja/Days/day36.md b/2022/ja/Days/day36.md index 68e964f..2f4f934 100644 --- a/2022/ja/Days/day36.md +++ b/2022/ja/Days/day36.md @@ -136,7 +136,7 @@ Some of the major benefits of Git are: - Flexible - Safe & Secure -Unlike the Client-Server version control model, each developer downloads the the source repository meaning everything. History of commits, all the branches etc. etc. +Unlike the Client-Server version control model, each developer downloads the source repository meaning everything. History of commits, all the branches etc. etc. ![](Images/Day36_Git16.png) diff --git a/2022/ja/Days/day56.md b/2022/ja/Days/day56.md index d90c093..9dc3beb 100644 --- a/2022/ja/Days/day56.md +++ b/2022/ja/Days/day56.md @@ -58,7 +58,7 @@ With Infrastructure as Code we have the ability to automate all these tasks end This can be used in almost all platforms, virtualisation, cloud based workloads and also cloud-native infrastructure such as Kubernetes and containers. ### Infrastructure Provisioning -Not all IaC cover all of the below, You will find that the tool we are going to be using during this section only really covers the the first 2 areas of below; Terraform is that tool we will be covering and this allows us to start from nothing and define in code what our infrastructure should look like and then deploy that, it will also enable us to manage that infrastructure and also initially deploy an application but at that point it is going to lose track of the application which is where the next section comes in and something like Ansible as a configuration management tool might work better on that front. +Not all IaC cover all of the below, You will find that the tool we are going to be using during this section only really covers the first 2 areas of below; Terraform is that tool we will be covering and this allows us to start from nothing and define in code what our infrastructure should look like and then deploy that, it will also enable us to manage that infrastructure and also initially deploy an application but at that point it is going to lose track of the application which is where the next section comes in and something like Ansible as a configuration management tool might work better on that front. Without jumping ahead tools like chef, puppet and ansible are best suited to deal with the initial application setup and then to manage those applications and their configuration. diff --git a/2022/ja/Days/day68.md b/2022/ja/Days/day68.md index c25eb5c..9075b63 100644 --- a/2022/ja/Days/day68.md +++ b/2022/ja/Days/day68.md @@ -48,7 +48,7 @@ tags can be added at the task level as well so we can get really granular on whe `tag: always` this will ensure no matter what --tags you are using in your command if something is tagged with the always value then it will always be ran when you run the ansible-playbook command. -With tags we can also bundle multiple tags together and if we choose to run `ansible-playbook playbook5.yml --tags proxy,web` this will run all of the items with those tags. Obviously in our instance that would mean the same as running the the playbook but if we had multiple other plays then this would make sense. +With tags we can also bundle multiple tags together and if we choose to run `ansible-playbook playbook5.yml --tags proxy,web` this will run all of the items with those tags. Obviously in our instance that would mean the same as running the playbook but if we had multiple other plays then this would make sense. You can also define more than one tag. diff --git a/2022/pl/day56.md b/2022/pl/day56.md index c4bad6c..47035fc 100644 --- a/2022/pl/day56.md +++ b/2022/pl/day56.md @@ -58,7 +58,7 @@ With Infrastructure as Code we have the ability to automate all these tasks end This can be used in almost all platforms, virtualisation, cloud based workloads and also cloud-native infrastructure such as Kubernetes and containers. ### Infrastructure Provisioning -Not all IaC cover all of the below, You will find that the tool we are going to be using during this section only really covers the the first 2 areas of below; Terraform is that tool we will be covering and this allows us to start from nothing and define in code what our infrastructure should look like and then deploy that, it will also enable us to manage that infrastructure and also initially deploy an application but at that point it is going to lose track of the application which is where the next section comes in and something like Ansible as a configuration management tool might work better on that front. +Not all IaC cover all of the below, You will find that the tool we are going to be using during this section only really covers the first 2 areas of below; Terraform is that tool we will be covering and this allows us to start from nothing and define in code what our infrastructure should look like and then deploy that, it will also enable us to manage that infrastructure and also initially deploy an application but at that point it is going to lose track of the application which is where the next section comes in and something like Ansible as a configuration management tool might work better on that front. Without jumping ahead tools like chef, puppet and ansible are best suited to deal with the initial application setup and then to manage those applications and their configuration. diff --git a/2022/pl/day68.md b/2022/pl/day68.md index c25eb5c..9075b63 100644 --- a/2022/pl/day68.md +++ b/2022/pl/day68.md @@ -48,7 +48,7 @@ tags can be added at the task level as well so we can get really granular on whe `tag: always` this will ensure no matter what --tags you are using in your command if something is tagged with the always value then it will always be ran when you run the ansible-playbook command. -With tags we can also bundle multiple tags together and if we choose to run `ansible-playbook playbook5.yml --tags proxy,web` this will run all of the items with those tags. Obviously in our instance that would mean the same as running the the playbook but if we had multiple other plays then this would make sense. +With tags we can also bundle multiple tags together and if we choose to run `ansible-playbook playbook5.yml --tags proxy,web` this will run all of the items with those tags. Obviously in our instance that would mean the same as running the playbook but if we had multiple other plays then this would make sense. You can also define more than one tag. diff --git a/2022/zh_cn/Days/day56.md b/2022/zh_cn/Days/day56.md index d90c093..9dc3beb 100644 --- a/2022/zh_cn/Days/day56.md +++ b/2022/zh_cn/Days/day56.md @@ -58,7 +58,7 @@ With Infrastructure as Code we have the ability to automate all these tasks end This can be used in almost all platforms, virtualisation, cloud based workloads and also cloud-native infrastructure such as Kubernetes and containers. ### Infrastructure Provisioning -Not all IaC cover all of the below, You will find that the tool we are going to be using during this section only really covers the the first 2 areas of below; Terraform is that tool we will be covering and this allows us to start from nothing and define in code what our infrastructure should look like and then deploy that, it will also enable us to manage that infrastructure and also initially deploy an application but at that point it is going to lose track of the application which is where the next section comes in and something like Ansible as a configuration management tool might work better on that front. +Not all IaC cover all of the below, You will find that the tool we are going to be using during this section only really covers the first 2 areas of below; Terraform is that tool we will be covering and this allows us to start from nothing and define in code what our infrastructure should look like and then deploy that, it will also enable us to manage that infrastructure and also initially deploy an application but at that point it is going to lose track of the application which is where the next section comes in and something like Ansible as a configuration management tool might work better on that front. Without jumping ahead tools like chef, puppet and ansible are best suited to deal with the initial application setup and then to manage those applications and their configuration. diff --git a/2022/zh_cn/Days/day68.md b/2022/zh_cn/Days/day68.md index c25eb5c..9075b63 100644 --- a/2022/zh_cn/Days/day68.md +++ b/2022/zh_cn/Days/day68.md @@ -48,7 +48,7 @@ tags can be added at the task level as well so we can get really granular on whe `tag: always` this will ensure no matter what --tags you are using in your command if something is tagged with the always value then it will always be ran when you run the ansible-playbook command. -With tags we can also bundle multiple tags together and if we choose to run `ansible-playbook playbook5.yml --tags proxy,web` this will run all of the items with those tags. Obviously in our instance that would mean the same as running the the playbook but if we had multiple other plays then this would make sense. +With tags we can also bundle multiple tags together and if we choose to run `ansible-playbook playbook5.yml --tags proxy,web` this will run all of the items with those tags. Obviously in our instance that would mean the same as running the playbook but if we had multiple other plays then this would make sense. You can also define more than one tag. diff --git a/2022/zh_tw/Days/day36.md b/2022/zh_tw/Days/day36.md index 68e964f..2f4f934 100644 --- a/2022/zh_tw/Days/day36.md +++ b/2022/zh_tw/Days/day36.md @@ -136,7 +136,7 @@ Some of the major benefits of Git are: - Flexible - Safe & Secure -Unlike the Client-Server version control model, each developer downloads the the source repository meaning everything. History of commits, all the branches etc. etc. +Unlike the Client-Server version control model, each developer downloads the source repository meaning everything. History of commits, all the branches etc. etc. ![](Images/Day36_Git16.png) diff --git a/2022/zh_tw/Days/day56.md b/2022/zh_tw/Days/day56.md index d90c093..9dc3beb 100644 --- a/2022/zh_tw/Days/day56.md +++ b/2022/zh_tw/Days/day56.md @@ -58,7 +58,7 @@ With Infrastructure as Code we have the ability to automate all these tasks end This can be used in almost all platforms, virtualisation, cloud based workloads and also cloud-native infrastructure such as Kubernetes and containers. ### Infrastructure Provisioning -Not all IaC cover all of the below, You will find that the tool we are going to be using during this section only really covers the the first 2 areas of below; Terraform is that tool we will be covering and this allows us to start from nothing and define in code what our infrastructure should look like and then deploy that, it will also enable us to manage that infrastructure and also initially deploy an application but at that point it is going to lose track of the application which is where the next section comes in and something like Ansible as a configuration management tool might work better on that front. +Not all IaC cover all of the below, You will find that the tool we are going to be using during this section only really covers the first 2 areas of below; Terraform is that tool we will be covering and this allows us to start from nothing and define in code what our infrastructure should look like and then deploy that, it will also enable us to manage that infrastructure and also initially deploy an application but at that point it is going to lose track of the application which is where the next section comes in and something like Ansible as a configuration management tool might work better on that front. Without jumping ahead tools like chef, puppet and ansible are best suited to deal with the initial application setup and then to manage those applications and their configuration. diff --git a/2022/zh_tw/Days/day68.md b/2022/zh_tw/Days/day68.md index c25eb5c..9075b63 100644 --- a/2022/zh_tw/Days/day68.md +++ b/2022/zh_tw/Days/day68.md @@ -48,7 +48,7 @@ tags can be added at the task level as well so we can get really granular on whe `tag: always` this will ensure no matter what --tags you are using in your command if something is tagged with the always value then it will always be ran when you run the ansible-playbook command. -With tags we can also bundle multiple tags together and if we choose to run `ansible-playbook playbook5.yml --tags proxy,web` this will run all of the items with those tags. Obviously in our instance that would mean the same as running the the playbook but if we had multiple other plays then this would make sense. +With tags we can also bundle multiple tags together and if we choose to run `ansible-playbook playbook5.yml --tags proxy,web` this will run all of the items with those tags. Obviously in our instance that would mean the same as running the playbook but if we had multiple other plays then this would make sense. You can also define more than one tag. diff --git a/2023/day58.md b/2023/day58.md index cef241d..92e43e3 100644 --- a/2023/day58.md +++ b/2023/day58.md @@ -297,7 +297,7 @@ In the middle (3) we have an overall status of the cluster, and connectivity to Clicking the Administrator word in the top left-hand side (above screenshot, 1), you can switch to the Developer mode, which you can see below. -On the the developer homepage screen, you can see straight away you are presented with a rich-deployment options to get up and running, you can deploy Kubernetes Operators for services, Helm Charts, import code from Git which can be built into a container by the cluster, deploy app samples, bring in individual containers, import content from your local machine, and control who can access your projects (Kubernetes namespaces with more features added in). +On the developer homepage screen, you can see straight away you are presented with a rich-deployment options to get up and running, you can deploy Kubernetes Operators for services, Helm Charts, import code from Git which can be built into a container by the cluster, deploy app samples, bring in individual containers, import content from your local machine, and control who can access your projects (Kubernetes namespaces with more features added in). ![Red Hat OpenShift - Web Console - Developer Homepage](images/Day58%20-%20OpenShift%20Cluster%20Install/Red%20Hat%20OpenShift%20-%20Web%20Console%20-%20Developer%20Homepage.jpg) diff --git a/2023/day81.md b/2023/day81.md index f5cd8ed..de1a7d3 100644 --- a/2023/day81.md +++ b/2023/day81.md @@ -85,7 +85,7 @@ There's much more to what we can see in Prometheus. If you have this up in your Hit *ctrl+c* to exist the dashboard process. ### Grafana -Grafana is an open-source and multi-platform analystics and visualization system that can be deployed alongside Prometheus to help us visually chart our apps and infra performance. +Grafana is an open-source and multi-platform analytics and visualization system that can be deployed alongside Prometheus to help us visually chart our apps and infra performance. I've already installed the sample addons which contained Grafana. Let's check the services and see that it's there. diff --git a/2024/day11.md b/2024/day11.md index 434ae6f..d5f5d4c 100644 --- a/2024/day11.md +++ b/2024/day11.md @@ -30,7 +30,7 @@ International speaker, holds Philosophy B.A & M.A degrees, plays the piano and t
-## DRP Resoruces +## DRP Resources #### Code examples diff --git a/2024/day16.md b/2024/day16.md index b546309..8810bfa 100644 --- a/2024/day16.md +++ b/2024/day16.md @@ -15,7 +15,7 @@ ## Overview -Performance testing has long been a critical part of a DevOps engineer's toolbox, allowing engineers to better understand the systems they build and maintain by simulating varying degrees of traffic at scale. However, existing performance frameworks are often limited in their ability to simulate realistic user scenarios at scale. Additionaly, performance testing frameworks are almost universally infamous for their poor developer/user experience, difficulty in integration with CI/CD and modern cloud environments, and lack of built-in quality reporting options. +Performance testing has long been a critical part of a DevOps engineer's toolbox, allowing engineers to better understand the systems they build and maintain by simulating varying degrees of traffic at scale. However, existing performance frameworks are often limited in their ability to simulate realistic user scenarios at scale. Additionally, performance testing frameworks are almost universally infamous for their poor developer/user experience, difficulty in integration with CI/CD and modern cloud environments, and lack of built-in quality reporting options. Simulation frameworks represent the next step in performance testing, delivering on performance frameworks' core value proposition(s) while extending their functionality to embrace new testing techniques and modern developer needs. Simulation frameworks achieve this by: @@ -79,7 +79,7 @@ The majority of performance testing frameworks neglect or are outright incompati - Having to write custom integration reporting plugins or integrate clunky third-party options in order to publish test results to modern DevOps analytics platforms. -- Having to effectively micromanage deployment to avoid OOM or other compatability issues with CI/CD pipelines or distributed environments like Kubernetes. +- Having to effectively micromanage deployment to avoid OOM or other compatibility issues with CI/CD pipelines or distributed environments like Kubernetes. - Having to "guess" appropriate testing configuration values not just for initial testing but after infrastructure or application changes, resulting in significant time wasted manually tweaking tests to get good signal on the impact of changes. @@ -214,7 +214,7 @@ However, the granularity of unit tests can make composing them into meaningful t ### A|B Testing, Chaos, and Learned Configuration -One of the the most frequent (and awkward) questions engineers encounter when setting up performance testing is - "how should I setup this test"? While existing application analystics can provide insight into how an application performs now, we want to account for unexpected and future scenarios. +One of the most frequent (and awkward) questions engineers encounter when setting up performance testing is - "how should I setup this test"? While existing application analytics can provide insight into how an application performs now, we want to account for unexpected and future scenarios. Simply setting concurrency to maximum will likely cause the application to fail, but will provide no insight as to where issues begin to arise. Likewise, setting concurrency too low means the application will not be placed under proper stress, resulting in test results delivering no value. This challenge compounds when testing different environments (such as development or staging environments) which may have differing levels of resource allocation. diff --git a/2024/day27.md b/2024/day27.md index 4c010e0..b1343d5 100644 --- a/2024/day27.md +++ b/2024/day27.md @@ -11,7 +11,7 @@ A universal truth and recurring theme in the DevOps world is automation. From providing infrastructure to testing code to deploying to production, many parts of the DevOps lifecycle get automated already. One popular technology for managing infrastructure and configuration in an automated way is Ansible, but are we fully utilizing its capabilities yet? -This presentation will give a broad overview of Ansible and its architecture and use-cases, before exploring a relatively new feature, Event-driven Ansible (EDA). Analzying applications of event-driven Ansible, participants will see that automated management is nice, but automatic management is awesome, not just regarding DevOps principles, but also in terms of reaction times, the human tendency for minor mistakes, and toil for operators. +This presentation will give a broad overview of Ansible and its architecture and use-cases, before exploring a relatively new feature, Event-driven Ansible (EDA). Analyzing applications of event-driven Ansible, participants will see that automated management is nice, but automatic management is awesome, not just regarding DevOps principles, but also in terms of reaction times, the human tendency for minor mistakes, and toil for operators. Participants will get first-hand insights into Ansible, its strengths, weaknesses, and the potential of event-driven automation within the DevOps world. @@ -242,7 +242,7 @@ Jan 11 16:35:29 eda-controller ansible-rulebook[56882]: {'payload': {'foo': 'bar 'received_at': '2024-01-11T15:35:29.798401Z', 'uuid': '6ebf8dd2-60a2-455a-9383-97b81f535366'}} ``` -A rule that always evaluates to `true` is not very useful, so let's change the rule to only print the the value of `foo` if the `foo` key is present in the event's payload, and `no foo :(` otherwise: +A rule that always evaluates to `true` is not very useful, so let's change the rule to only print the value of `foo` if the `foo` key is present in the event's payload, and `no foo :(` otherwise: ```yaml --- diff --git a/publishing.md b/publishing.md index 357b4e6..1fe0177 100644 --- a/publishing.md +++ b/publishing.md @@ -30,7 +30,7 @@ When you have the converted file we will want to add - Front Cover - Possibly look at either using readme.md and the blog to introduce - A table of contents -- Special Thanks & Contributers +- Special Thanks & Contributors - Repository Info ### Markdown to PDF