mirror of
https://github.com/MichaelCade/90DaysOfDevOps.git
synced 2025-01-13 00:04:57 +07:00
Merge branch 'main' into feature/translateES
This commit is contained in:
commit
736a75e61e
BIN
Days/Images/Day43_EnableWSL.png
Normal file
BIN
Days/Images/Day43_EnableWSL.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 56 KiB |
BIN
Days/Images/Day43_check.png
Normal file
BIN
Days/Images/Day43_check.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 63 KiB |
BIN
Days/Images/Day43_install.png
Normal file
BIN
Days/Images/Day43_install.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 67 KiB |
BIN
Days/Images/Day43_operatingSystem.png
Normal file
BIN
Days/Images/Day43_operatingSystem.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 50 KiB |
@ -10,7 +10,7 @@ id: 1048862
|
||||
|
||||
Before we get into the topics for today I want to give a massive shout out to [Techworld with Nana](https://www.youtube.com/watch?v=yyUHQIec83I) and this fantastic concise journey through the fundamentals of Go.
|
||||
|
||||
On [Day8](day08.md) we set our environment up, on [Day9](day09.md) we walked through the Hello #90DaysOfDevOps code and on [Day10](day10.md)) we looked at our Go workspace and went a little deeper into compiling and running the code.
|
||||
On [Day8](day08.md) we set our environment up, on [Day9](day09.md) we walked through the Hello #90DaysOfDevOps code and on [Day10](day10.md) we looked at our Go workspace and went a little deeper into compiling and running the code.
|
||||
|
||||
Today we are going to take a look into Variables, Constants and Data Types whilst writing a new program.
|
||||
|
||||
|
@ -99,7 +99,7 @@ If you are like me and you use that `clear` command a lot then you might miss so
|
||||
|
||||
When you run `history` and you would like to pick a specific command you can use `!3` to choose the 3rd command in the list.
|
||||
|
||||
You are also able to use `history | grep "Command` to search for something specific.
|
||||
You are also able to use `history | grep "Command"` to search for something specific.
|
||||
|
||||
On servers to trace back when was a command executed, it can be useful to append the date and time to each command in the history file.
|
||||
|
||||
|
@ -40,7 +40,7 @@ Branching allows for two code streams for the same app as we stated above. But w
|
||||
|
||||
![](Images/Day35_Git4.png)
|
||||
|
||||
Now, this same easy but merging can be complicated because you could have a team working on the free edition and you could have another team working on the premium paid-for version and what if both change code that affects aspects of the overall code. Maybe a variable gets updated and breaks something. Then you have a conflict that breaks one of the features. Version Control cannot fix the conflicts that are down to you. But version control allows this to be easily managed.
|
||||
Now, this seems easy but merging can be complicated because you could have a team working on the free edition and you could have another team working on the premium paid-for version and what if both change code that affects aspects of the overall code. Maybe a variable gets updated and breaks something. Then you have a conflict that breaks one of the features. Version Control cannot fix the conflicts that are down to you. But version control allows this to be easily managed.
|
||||
|
||||
The primary reason if you have not picked up so far for version control, in general, is the ability to collaborate. The ability to share code amongst developers and when I say code as I said before more and more we are seeing much more use cases for other reasons to use source control, maybe its a joint presentation you are working on with a colleague or a 90DaysOfDevOps challenge where you have the community offering their corrections and updates throughout the project.
|
||||
|
||||
|
@ -61,6 +61,22 @@ The [docker documenation](https://docs.docker.com/engine/install/) is amazing an
|
||||
Take note before you go ahead and install at the system requirements, [Install Docker Desktop on Windows](https://docs.docker.com/desktop/windows/install/) if you are using macOS including the M1-based CPU architecture you can also take a look at [Install Docker Desktop on macOS](https://docs.docker.com/desktop/mac/install/)
|
||||
|
||||
I will run through the Docker Desktop installation for Windows on another Windows Machine and log the process down below.
|
||||
### Windows
|
||||
|
||||
- Select windows as the operating system of your device.
|
||||
|
||||
<img src = Images/Day43_operatingSystem.png>
|
||||
|
||||
- Navigate to the folder where you want to save the installer and save.
|
||||
|
||||
- Run the installer and wait for a few seconds and grant access for WSL.
|
||||
<img src = Images/Day43_EnableWSL.png>
|
||||
|
||||
- Click ok and the installation will begin.
|
||||
<img src = Images/Day43_install.png>
|
||||
|
||||
- Docker Desktop has been successfully installed on your device. You can now run the command "docker" on the terminal to check if the installation was successfull.
|
||||
<img src = Images/Day43_check.png>
|
||||
|
||||
## Resources
|
||||
|
||||
|
@ -150,6 +150,7 @@ I added this list to the post yesterday which are walkthrough blogs I have done
|
||||
- [Kubernetes, How to – AWS Bottlerocket + Amazon EKS](https://vzilla.co.uk/vzilla-blog/kubernetes-how-to-aws-bottlerocket-amazon-eks)
|
||||
- [Getting started with CIVO Cloud](https://vzilla.co.uk/vzilla-blog/getting-started-with-civo-cloud)
|
||||
- [Minikube - Kubernetes Demo Environment For Everyone](https://vzilla.co.uk/vzilla-blog/project_pace-kasten-k10-demo-environment-for-everyone)
|
||||
- [Minikube - Deploy Minikube Using Vagrant and Ansible on VirtualBox](https://medium.com/techbeatly/deploy-minikube-using-vagrant-and-ansible-on-virtualbox-infrastructure-as-code-2baf98188847)
|
||||
|
||||
### What we will cover in the series on Kubernetes
|
||||
|
||||
@ -172,5 +173,6 @@ If you have FREE resources that you have used then please feel free to add them
|
||||
- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
|
||||
- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
|
||||
- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
|
||||
- [Techbeatly - Deploy Minikube Using Vagrant and Ansible on VirtualBox](https://www.youtube.com/watch?v=xPLQqHbp9BM&t=371s)
|
||||
|
||||
See you on [Day 52](day52.md)
|
||||
|
@ -4,7 +4,7 @@
|
||||
<img src="logo.png?raw=true" alt="90DaysOfDevOps Logo" width="50%" height="50%" />
|
||||
</p>
|
||||
|
||||
English Version | [Versión en Castellano](es/README.md) | [中文版本](zh_cn/README.md) | [繁體中文版本](zh_tw/README.md)| [日本語版](ja/README.md) | [Wersja Polska](pl/README.md) | [Tiếng Việt](vi/README.md)
|
||||
English Version | [Versión en Castellano](es/README.md) | [中文版本](zh_cn/README.md) | [繁體中文版本](zh_tw/README.md)| [日本語版](ja/README.md) | [Wersja Polska](pl/README.md) | [Tiếng Việt](vi/README.md) | [한국어](ko/README.md)
|
||||
|
||||
This repository is used to document my journey on getting a better foundational knowledge of "DevOps". I will be starting this journey on the 1st January 2022 but the idea is that we take 90 days which just so happens to be January 1st to March 31st.
|
||||
|
||||
|
BIN
dockerImages/config.png
Normal file
BIN
dockerImages/config.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 19 KiB |
@ -1,83 +1,84 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - The Big Picture: DevOps and Networking - Day 21'
|
||||
title: '#90DaysOfDevOps - 全体像: DevOpsとネットワーキング - 21日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - The Big Picture DevOps and Networking
|
||||
description: 90DaysOfDevOps - DevOpsとネットワーキング
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048761
|
||||
---
|
||||
## The Big Picture: DevOps and Networking
|
||||
## 全体像: DevOpsとネットワーキング
|
||||
|
||||
Welcome to Day 21! We are going to be getting into Networking over the next 7 days, Networking and DevOps is the overarching theme but we will need to get into some of the networking fundamentals as well.
|
||||
21日目へようこそ! ネットワークとDevOpsは包括的なテーマですが、ネットワークの基本的な部分にも触れる必要があります。
|
||||
|
||||
Ultimately as we have said previously DevOps is about a culture and process change within your organisations this as we have discussed can be Virtual Machines, Containers, Kubernetes but it can also be the network, If we are using those DevOps principles for our infrastructure that has to include the network more to the point from a DevOps point of view you also need to know about the network as in the different topologies and networking tools and stacks that we have available.
|
||||
最終的には、これまで述べてきたように、DevOpsは組織内の文化やプロセスを変えることなのです。
|
||||
私たちは、仮想マシン、コンテナ、Kubernetesについて議論してきました。もし私たちがインフラストラクチャにDevOpsの原則を用いるのであれば、DevOpsの観点からすると、ネットワークも含まれなければなりません。ネットワークについても、さまざまなトポロジーやネットワーク・ツール、スタックについて知っておく必要があります。
|
||||
|
||||
I would argue that we should have our networking devices configured using infrastructure as code and have everything automated like we would our virtual machines, but in order to do that we have to have a good understanding of what we are automating.
|
||||
私は、インフラストラクチャー・アズ・コードを使ってネットワーク機器を設定し、仮想マシンのようにすべてを自動化すべきだと主張します。しかし、そのためには、何を自動化するのかをよく理解しなければなりません。
|
||||
|
||||
### What is NetDevOps | Network DevOps?
|
||||
### NetDevOpsとは
|
||||
|
||||
You may also hear the terms Network DevOps or NetDevOps. Maybe you are already a Network engineer and have a great grasp on the network components within the infrastructure you understand the elements used around networking such as DHCP, DNS, NAT etc etc. You will also have a good understanding around the hardware or software defined networking options, switches, routers etc etc.
|
||||
また、Network DevOpsやNetDevOpsという言葉も耳にすることがあるかもしれません。あなたはすでにネットワーク・エンジニアで、インフラ内のネットワーク・コンポーネントをよく理解しており、DHCP、DNS、NATなど、ネットワーキングで使用される要素を理解しているかもしれません。また、ハードウェアやソフトウェア定義のネットワークオプション、スイッチ、ルーターなどについてもよく理解していることでしょう。
|
||||
|
||||
But if you are not a network engineer then we probably need to get a foundational knowledge across the board on some of those areas so that we can understand the end goal of Network DevOps.
|
||||
しかし、もしあなたがネットワークエンジニアでないなら、ネットワークDevOpsの最終目標を理解するために、これらの分野の基礎知識を得る必要があるかもしれません。
|
||||
|
||||
But in regards to those terms we can think of NetDevOps or Network DevOps as applying the DevOps Principles and Practices to the network, applying version control and automation tools to the network creation, testing, monitoring, and deployments.
|
||||
しかし、これらの用語に関して、NetDevOpsまたはネットワークDevOpsは、DevOpsの原則と実践をネットワークに適用し、バージョン管理と自動化ツールをネットワークの作成、テスト、監視、デプロイメントに適用することだと考えることができます。
|
||||
|
||||
If we think of Network DevOps of having to require automation, we mentioned before about DevOps breaking down the siloes between teams. If the networking teams do not change to a similar model and process then they become the bottleneck or even the failure overall.
|
||||
自動化を必要とするネットワークDevOpsを考える場合、DevOpsはチーム間のサイロを破壊すると前述した。もしネットワーク・チームが同じようなモデルとプロセスに変わらなければ、彼らがボトルネックになったり、全体的に失敗したりすることになります。
|
||||
|
||||
Using the automation principles around provisioning, configuration, testing, version control and deployment is a great start. Automation is overall going to enable speed of deployment, stability of the networking infrastructure and consistent improvement as well as the process being shared across multiple environments once they have been tested. Such as a fully tested Network Policy that has been fully tested on one environment can be used quickly in another location because of the nature of this being in code vs a manually authored process which it might have been before.
|
||||
A really good view point and outline of this thinking can be found here. [Network DevOps](https://www.thousandeyes.com/learning/techtorials/network-devops)
|
||||
プロビジョニング、コンフィグレーション、テスト、バージョン管理、デプロイメントに関する自動化の原則を使用することは、素晴らしいスタートとなります。自動化は全体として、展開のスピード、ネットワークインフラの安定性、一貫した改善を可能にし、一度テストされたプロセスは複数の環境間で共有されるようになる。例えば、ある環境で完全にテストされたネットワークポリシーは、以前は手動でオーサリングされたプロセスであったのに対し、コード化されているため、別の場所でもすぐに使用することができる。
|
||||
この考え方の良い視点とアウトラインは、ここで見ることができます。[Network DevOps](https://www.thousandeyes.com/learning/techtorials/network-devops)
|
||||
|
||||
## Networking The Basics
|
||||
## ネットワーク基本
|
||||
|
||||
Let's forget the DevOps side of things to begin with here and we now need to look very briefly into some of the Networking fundamentals.
|
||||
ここでは、まずDevOpsの側面を忘れて、ネットワークの基本的な部分をごく簡単に見ていく必要があります。
|
||||
|
||||
### Network Devices
|
||||
### ネットワークデバイス
|
||||
|
||||
**Host** are any devices which sends or recieve traffic.
|
||||
**ホスト**は、トラフィックを送信または受信するすべてのデバイスです。
|
||||
|
||||
![](Images/Day21_Networking1.png)
|
||||
|
||||
**IP Address** the identity of each host.
|
||||
**IPアドレス** 各ホストのID。
|
||||
|
||||
![](Images/Day21_Networking2.png)
|
||||
|
||||
**Network** is what transports traffic between hosts. If we did not have networks there would be a lot of manual movement of data!
|
||||
**ネットワーク**は、ホスト間のトラフィックを転送するものです。もしネットワークがなければ、手作業によるデータの移動がたくさんあったことでしょう。
|
||||
|
||||
A logical group of hosts which require similar connectivity.
|
||||
ネットワークとは、同じような接続性を必要とするホストの論理的なグループです。
|
||||
|
||||
![](Images/Day21_Networking3.png)
|
||||
|
||||
**Switches** facilitate communication ***within*** a network. A switch forwards data packets between hosts. A switch sends packets directly to hosts.
|
||||
**スイッチ**は、ネットワーク内の通信を容易にします。スイッチは、ホスト間でデータパケットを転送します。スイッチは、パケットをホストに直接送信します。
|
||||
|
||||
- Network: A Grouping of hosts which require similar connectivity.
|
||||
- Hosts on a Network share the same IP address space.
|
||||
- ネットワークは、同じような接続性を必要とするホストのグループ化。
|
||||
- ネットワーク上のホストは、同じIPアドレス空間を共有する。
|
||||
|
||||
![](Images/Day21_Networking4.png)
|
||||
|
||||
**Router** facilitate communication between networks. If we said before that a switch looks after communication within a network a router allows us to join these networks together or at least give them access to each other if permitted.
|
||||
**ルータ**はネットワーク間の通信を容易にします。スイッチがネットワーク内の通信を管理すると言った場合、ルータはこれらのネットワークを結合したり、許可されていれば少なくとも相互にアクセスできるようにします。
|
||||
|
||||
A router can provide a traffic contol point (security, filtering, redirting) More and more switches also provide some of these functions now.
|
||||
ルーターは、トラフィック制御ポイント(セキュリティ、フィルタリング、リダイレクト)を提供することができます。
|
||||
|
||||
Routers learn which networks they are attached to. This is known as routes, a routing table is all the networks a router knows about.
|
||||
ルーターは、自分がどのネットワークに接続しているかを学習します。これはルートとして知られており、ルーティングテーブルは、ルータが知っているすべてのネットワークです。
|
||||
|
||||
A router has an IP address in the networks they are attached to. This IP is also going to be each hosts way out of their local network also known as a gateway.
|
||||
ルータは、それらが接続されているネットワークにIPアドレスを持っています。このIPはまた、ゲートウェイとして知られている彼らのローカルネットワークから各ホストの方法であることを行っている。
|
||||
|
||||
Routers also create the hierarchy in networks I mentioned earlier.
|
||||
ルータはまた、私が先に述べたネットワーク内の階層を作成します。
|
||||
|
||||
![](Images/Day21_Networking5.png)
|
||||
|
||||
## Switches vs Routers
|
||||
## スイッチとルーター
|
||||
|
||||
**Routing** is the process of moving data between networks.
|
||||
|
||||
- A router is a device whose primary purpose is Routing.
|
||||
**ルーティング**とは、ネットワーク間でデータを移動させる処理のことです。
|
||||
|
||||
**Switching** is the process of moving data within networks.
|
||||
- ルーターは、ルーティングを主目的とする装置である。
|
||||
|
||||
- A Switch is a device who's primary purpose is switching.
|
||||
**スイッチング**は、ネットワーク内でデータを移動させるプロセスです。
|
||||
|
||||
This is very much a foundational overview of devices as we know there are many different Network Devices such as:
|
||||
- スイッチとは、スイッチングを主目的とするデバイスのことです。
|
||||
|
||||
ネットワーク機器には、次のようなさまざまなものがあるため、ここでは機器の基礎的な概要を説明します。
|
||||
|
||||
- Access Points
|
||||
- Firewalls
|
||||
@ -88,9 +89,9 @@ This is very much a foundational overview of devices as we know there are many d
|
||||
- Virtual Switches
|
||||
- Virtual Routers
|
||||
|
||||
Although all of these devices are going to perform Routing and/or Switching.
|
||||
これらのデバイスはすべてルーティングとスイッチングを実行するものですが、このリストについてもう少し詳しく説明します。
|
||||
|
||||
Over the next few days we are going to get to know a little more about this list.
|
||||
これから数日間で、このリストについてもう少し詳しく知ることになります。
|
||||
|
||||
- OSI Model
|
||||
- Network Protocols
|
||||
@ -99,8 +100,8 @@ Over the next few days we are going to get to know a little more about this list
|
||||
- DHCP
|
||||
- Subnets
|
||||
|
||||
## Resources
|
||||
## リソース
|
||||
|
||||
[Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
|
||||
|
||||
See you on [Day22](day22.md)
|
||||
また[Day22](day22.md)でお会いしましょう。
|
||||
|
@ -1,98 +1,104 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - The OSI Model - The 7 Layers - Day 22'
|
||||
title: '#90DaysOfDevOps - OSIモデル - 7つのレイヤー - 22日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - The OSI Model - The 7 Layers
|
||||
description: 90DaysOfDevOps - OSIモデル - 7つのレイヤー
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1049037
|
||||
---
|
||||
## The OSI Model - The 7 Layers
|
||||
## OSIモデル - 7つのレイヤー
|
||||
|
||||
The overall purpose of networking as an industry is to allow two hosts to share data before networking if I want to get data from this host to this host I'd have to plug something into this host walk it over to the other host plug it into the other host.
|
||||
産業としてのネットワークの全体的な目的は、ネットワーク化する前に2つのホストがデータを共有できるようにすることです。
|
||||
このホストからこのホストにデータを送るには、このホストに何かを差し込んで、もう一方のホストまで歩いて行って、もう一方のホストに差し込まなければなりません。
|
||||
|
||||
Networking allows us to automate this by allowing the host to share data automatically across the wire for these hosts to do this they must follow a set of rules.
|
||||
ネットワーク化によって、ホストがワイヤーを介して自動的にデータを共有できるようになり、これを自動化することができるようになりました。
|
||||
|
||||
This is no different than any language English has a set of rules that two English speakers must follow Spanish has its own set of rules French has its own set of rules while networking also has its own set of rules
|
||||
これは、英語には英語を話す者同士が守らなければならないルールがあり、スペイン語にはスペイン語のルールがあり、フランス語にはフランス語のルールがあるのと同じで、ネットワークにもルールがあります。
|
||||
|
||||
The rules for networking are divided into seven different layers and those layers are known as the OSI model.
|
||||
ネットワークのルールは7つの層に分かれており、それらの層はOSIモデルとして知られています。
|
||||
|
||||
### Introduction to the OSI Model
|
||||
### OSIモデルの紹介
|
||||
|
||||
The OSI Model (Open Systems Interconnection Model) is a framework used to describe the functions of a networking system. The OSI model characterises computing functions into a universal set of rules and requirements in order to support interoperability between different products and software. In the OSI reference model, the communications between a computing system are split into seven different abstraction layers: **Physical, Data Link, Network, Transport, Session, Presentation, and Application**.
|
||||
OSIモデル(Open Systems Interconnection Model)は、ネットワークシステムの機能を記述するために使用されるフレームワークである。OSIモデルは、異なる製品やソフトウェア間の相互運用性をサポートするために、コンピューティング機能を普遍的な規則と要件のセットに特徴付けます。OSI参照モデルでは、コンピュータシステム間の通信は、7つの異なる抽象化層に分割されています。**物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層です。
|
||||
|
||||
![](Images/Day22_Networking1.png)
|
||||
|
||||
### Physical
|
||||
Layer 1 in the OSI model and this is known as physical, the premise of being able to get data from one host to another through a means be it physical cable or we could also consider Wi-Fi in this layer as well. We might also see some more legacy hardware seen here around hubs and repeaters in order to transport the data from one host to another.
|
||||
### 物理層
|
||||
|
||||
OSIモデルの第1層は物理層と呼ばれ、あるホストから別のホストへ、物理ケーブルやWi-Fiなどの手段でデータを転送することを前提にしています。また、あるホストから別のホストへデータを転送するために、ハブやリピータなどのレガシーハードウェアも見られるかもしれません。
|
||||
|
||||
![](Images/Day22_Networking2.png)
|
||||
|
||||
### Data Link
|
||||
Layer 2, the data link enables node to node transfer where data is packaged into frames. There is also a level of error correcting that might have occurred at the physical layer. This is also where we introduce or first see MAC addresses.
|
||||
### データリンク層
|
||||
|
||||
This is where we see the first mention of switches that we covered in our first day of networking on [Day 21](day21.md)
|
||||
レイヤ2、データリンクは、データがフレームにパッケージされているノード間の転送を可能にします。また、物理層で発生したであろうエラー訂正のレベルも存在する。また、MACアドレスを導入したり、初めて目にするのもこの層です。
|
||||
|
||||
21 日目](day21.md) のネットワーキングの初日で取り上げたスイッチについても、ここで初めて言及されています。
|
||||
|
||||
![](Images/Day22_Networking3.png)
|
||||
|
||||
### Network
|
||||
You have likely heard the term layer 3 switches or layer 2 switches. In our OSI model Layer 3, the Network has a goal of end to end delivery, this is where we see our IP addresses also mentioned in the first day overview.
|
||||
### ネットワーク層
|
||||
|
||||
Routers and hosts exist at layer 3, remember the router is the ability to route between multiple networks. Anything with an IP could be considered Layer 3.
|
||||
レイヤー3スイッチやレイヤー2スイッチという言葉を聞いたことがあると思います。OSIモデルのレイヤ3では、ネットワークはエンドツーエンドの配信を目標としており、初日の概要でも触れたIPアドレスはここにあたります。
|
||||
|
||||
ルータとホストはレイヤ3に存在し、ルータは複数のネットワーク間をルーティングする機能であることを忘れないでください。IPを持つものはすべてレイヤー3と考えることができます。
|
||||
|
||||
![](Images/Day22_Networking4.png)
|
||||
|
||||
So why do we need addressing schemes on both Layer 2 and 3? (MAC Addresses vs IP Addresses)
|
||||
では、なぜレイヤ2と3の両方でアドレス方式が必要なのでしょうか? (MACアドレスとIPアドレスの比較)
|
||||
|
||||
If we think about getting data from one host to another, each host has an IP address but there are several switches and routers in between. Each of the devices has that layer 2 MAC address.
|
||||
あるホストから別のホストにデータを送ることを考えると、各ホストはIPアドレスを持っていますが、その間にはいくつかのスイッチやルーターがあります。それぞれの機器には、そのレイヤー2のMACアドレスがあります。
|
||||
|
||||
The layer 2 MAC address will go from host to switch/router only, it is focused on hops where as the layer 3 IP addresses will stay with that packet of data until it reaches its end host. (End to End)
|
||||
レイヤー2 MACアドレスは、ホストからスイッチ/ルーターに移動するだけで、レイヤー3 IPアドレスがそのデータのパケットがエンドホストに到達するまで残るのに対し、ホップに焦点が当てられています。(エンド・ツー・エンド)
|
||||
|
||||
IP Addresses - Layer 3 = End to End Delivery
|
||||
IPアドレス - レイヤ3 = エンド・トゥ・エンド配送
|
||||
|
||||
MAC Addresses - Layer 2 = Hop to Hop Delivery
|
||||
MACアドレス - レイヤ2 = ホップ・トゥ・ホップ配送
|
||||
|
||||
Now there is a network protocol that we will get into but not today called ARP(Address Resolution Protocol) which links our Layer3 and Layer2 addresses.
|
||||
さて、レイヤ3とレイヤ2のアドレスを結びつけるARP(Address Resolution Protocol)というネットワークプロトコルがありますが、今日は触れません。
|
||||
|
||||
### Transport
|
||||
Service to Service delivery, Layer 4 is there to distinguish data streams. In the same way that Layer 3 and Layer 2 both had their addressing schemes in Layer 4 we have ports.
|
||||
### トランスポート層
|
||||
|
||||
サービスからサービスへ、レイヤ4はデータストリームを区別するために存在する。レイヤー3とレイヤー2がアドレス方式を持つのと同じように、レイヤー4にはポートがあります。
|
||||
|
||||
![](Images/Day22_Networking5.png)
|
||||
|
||||
### Session, Presentation, Application
|
||||
Distinction between Layers 5,6,7 is or had become somewhat vague.
|
||||
### セッション層、プレゼンテーション層、アプリケーション層
|
||||
|
||||
It is worth looking at the [TCP IP Model](https://www.geeksforgeeks.org/tcp-ip-model/) to get a more recent understanding.
|
||||
レイヤー5,6,7の区別は、やや曖昧になっている、あるいはなっていた。
|
||||
|
||||
Let's now try and explain what's actually happening when hosts are communicating to each other using this networking stack. This host has an application that's going to generate data that is meant to be sent to another host.
|
||||
[TCP IPモデル](https://www.geeksforgeeks.org/tcp-ip-model/)を見ると、より最新の理解が得られるでしょう。
|
||||
|
||||
The source host is going to go through is what's known as the encapsulation process. That data will be first sent to layer 4.
|
||||
では、このネットワークスタックを使ってホスト同士が通信しているときに、実際に何が起こっているかを説明しましょう。このホストには、別のホストに送信するデータを生成するアプリケーションがあります。
|
||||
|
||||
Layer 4 is going to add a header to that data which can facilitate the goal of layer 4 which is service to service delivery. This is going to be a port using either TCP or UDP. It is also going to include the source port and destination port.
|
||||
送信元のホストは、カプセル化プロセスと呼ばれるものを通過することになります。そのデータはまずレイヤー4に送られます。
|
||||
|
||||
This may also be known as a segment (Data and Port)
|
||||
レイヤ4はそのデータにヘッダを追加し、レイヤ4の目標であるサービス間デリバリーを容易にします。これは、TCPまたはUDPを使用したポートになります。また、送信元ポートと送信先ポートも含まれます。
|
||||
|
||||
This segment is going to be passed down the osi stack to layer 3, the network layer, the network layer is going to add another header to this data.
|
||||
This header is going to facilitate the goal of layer 3 which is end to end delivery meaning in this header you will have a source ip address and a destination ip, the header plus data may also be referred to as a packet.
|
||||
これは、セグメント(データとポート)とも呼ばれます。
|
||||
|
||||
Layer 3 will then take that packet and hand it off to layer 2, layer 2 will once again add another header to that data to accomplish layer 2's goal of hop to hop delivery meaning this header will include a source and destination mac address.
|
||||
This is known as a frame when you have the layer 2 header and data.
|
||||
このセグメントは、osiスタックからレイヤー3、ネットワーク層に渡されます。ネットワーク層はこのデータに別のヘッダを追加します。
|
||||
このヘッダはレイヤ3の目的であるエンド・ツー・エンド・デリバリを容易にします。つまり、このヘッダにはソースIPアドレスとデスティネーションIPがあり、ヘッダとデータはパケットと呼ばれることがあります。
|
||||
|
||||
That frame then gets converted into ones and zeros and sent over the Layer 1 Physical cable or wifi.
|
||||
レイヤ3はそのパケットをレイヤ2に渡します。レイヤ2は再びそのデータに別のヘッダを追加し、レイヤ2の目標であるホップ・トゥ・ホップ配送を達成します。
|
||||
このレイヤー2のヘッダーとデータを合わせて1つのフレームと呼びます。
|
||||
|
||||
このフレームは、1と0に変換され、レイヤ1物理ケーブルまたは無線LANで送信されます。
|
||||
|
||||
![](Images/Day22_Networking6.png)
|
||||
|
||||
I did mention above the naming for each layer of header plus data but decided to draw this out as well.
|
||||
ヘッダー+データの各レイヤーのネーミングについては前述しましたが、これも描き出すことにしました。
|
||||
|
||||
![](Images/Day22_Networking7.png)
|
||||
|
||||
Obviously the Application sending the data is being sent somewhere so the receiving in some what in reverse to get that back up the stack and into the receiving host.
|
||||
明らかに、データを送信しているアプリケーションは、どこかに送信されているので、受信側では逆にスタックを上がって受信側のホストにデータを戻します。
|
||||
|
||||
![](Images/Day22_Networking8.png)
|
||||
|
||||
## Resources
|
||||
## リソース
|
||||
|
||||
- [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
|
||||
- [Practical Networking](http://www.practicalnetworking.net/)
|
||||
|
||||
See you on [Day23](day23.md)
|
||||
[23日目](day23.md)でお会いしましょう。
|
||||
|
@ -1,119 +1,120 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Network Protocols - Day 23'
|
||||
title: '#90DaysOfDevOps - ネットワークプロトコル - 23日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Network Protocols
|
||||
description: 90DaysOfDevOps - ネットワークプロトコル
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048704
|
||||
---
|
||||
## Network Protocols
|
||||
## ネットワークプロトコル
|
||||
|
||||
A set of rules and messages that form a standard. An Internet Standard.
|
||||
標準を形成する一連の規則とメッセージ。
|
||||
インターネット標準の一つ。
|
||||
|
||||
- ARP - Address Resolution Protocol
|
||||
- ARP - アドレス解決プロトコル
|
||||
|
||||
If you want to get really into the weeds on ARP you can read the Internet Standard here. [RFC 826](https://datatracker.ietf.org/doc/html/rfc826)
|
||||
ARPについてもっと詳しく知りたい方は、こちらのインターネット標準をご覧ください。[RFC 826](https://datatracker.ietf.org/doc/html/rfc826)
|
||||
|
||||
Connects IP addresses to fixed physical machine addresses, also known as MAC addresses across a layer 2 network.
|
||||
レイヤ2ネットワークにおいて、IPアドレスをMACアドレスと呼ばれる固定物理マシンアドレスに接続する。
|
||||
|
||||
![](Images/Day23_Networking1.png)
|
||||
|
||||
- FTP - File Transfer Protocol
|
||||
- FTP - ファイル転送プロトコル
|
||||
|
||||
Allows for the transfer of files from source to destination. Generally this process is authenticated but there is the ability if configured to use anonymous access. You will more frequently now see FTPS which provides SSL/TLS connectivity to FTP servers from the client for better security. This protocol would be found in the Application layer of the OSI Model.
|
||||
送信元から送信先へのファイル転送を可能にする。一般に、このプロセスは認証されますが、匿名アクセスを使用するように設定されている場合は、その機能があります。現在では、より高いセキュリティのために、クライアントからFTPサーバーにSSL/TLS接続を提供するFTPSを目にすることが多くなっています。このプロトコルは、OSIモデルのアプリケーション層に位置づけられます。
|
||||
|
||||
![](Images/Day23_Networking2.png)
|
||||
|
||||
- SMTP - Simple Mail Transfer Protocol
|
||||
- SMTP - シンプルなメール転送プロトコル
|
||||
|
||||
Used for email transmission, mail servers use SMTP to send and recieve mail messages. You will still find even with Microsoft 365 that the SMTP protocol is used for the same purpose.
|
||||
電子メールの送信に使用され、メールサーバーはメールメッセージの送受信にSMTPを使用します。Microsoft 365 でも、SMTP プロトコルが同じ目的で使用されていることがわかります。
|
||||
|
||||
![](Images/Day23_Networking3.png)
|
||||
|
||||
- HTTP - Hyper Text Transfer Protocol
|
||||
- HTTP - ハイパーテキスト転送プロトコル
|
||||
|
||||
HTTP is the foundation of the internet and browsing content. Giving us the ability to easily access our favourite websites. HTTP is still heavily used but HTTPS is more so used or should be used on most of your favourite sites.
|
||||
HTTPは、インターネットとコンテンツ閲覧の基礎となるものです。お気に入りのWebサイトに簡単にアクセスできる機能を提供します。HTTPは今でもよく使われていますが、HTTPSはより多く使われており、お気に入りのサイトのほとんどで使われているはずです。
|
||||
|
||||
![](Images/Day23_Networking4.png)
|
||||
|
||||
- SSL - Secure Sockets Layer | TLS - Transport Layer Security
|
||||
- SSL - セキュア・ソケット・レイヤー|TLS - トランスポート・レイヤー・セキュリティ
|
||||
|
||||
TLS has taken over from SSL, TLS is a [Cryptographic Protocol]() that provides security communications over a network. It can and will be found in mail, im and other applications but most commonly it is used to secure HTTPS.
|
||||
TLSはSSLから引き継がれたもので、ネットワーク上でセキュリティ通信を提供する[暗号プロトコル]()です。TLSは、メール、im、その他のアプリケーションで使用されますが、最も一般的なのはHTTPSを保護するために使用されることです。
|
||||
|
||||
![](Images/Day23_Networking5.png)
|
||||
|
||||
- HTTPS - HTTP secured with SSL/TLS
|
||||
- HTTPS - SSL/TLSで保護されたHTTP
|
||||
|
||||
An extension of HTTP, used for secure communications over a network, HTTPS is encrypted with TLS as mentioned above. The focus here was to bring authenticaion, privacy and integrity whilst data is exchanged between hosts.
|
||||
ネットワーク上で安全な通信を行うために使用されるHTTPの拡張機能で、HTTPSは前述のようにTLSで暗号化されています。ホスト間でデータをやり取りする際に、信頼性、プライバシー、完全性を確保することに主眼が置かれています。
|
||||
|
||||
![](Images/Day23_Networking6.png)
|
||||
|
||||
- DNS - Domain Name System
|
||||
- DNS - ドメインネームシステム
|
||||
|
||||
The DNS is used to map human-freindly domain names for example we all know [google.com](https://google.com) but if you were to open a browser and put in [8.8.8.8](https://8.8.8.8) you would get Google as we pretty much know it. However good luck trying to remember all of the IP addresses for all of your websites where some of them we even use google to find information.
|
||||
DNSは、人間が自由に使えるドメイン名をマッピングするために使用されます。例えば、私たちは皆[google.com](https://google.com)を知っていますが、もしブラウザを開いて[8.8.8](https://8.8.8.8)を入力すれば、私たちがよく知るGoogleが得られるでしょう。しかし、我々は情報を見つけるためにGoogleを使用しても、それらのいくつかは、すべてのWebサイトのIPアドレスを覚えている幸運。
|
||||
|
||||
This is where DNS comes in, it ensures that hosts, services and other resources are reachable.
|
||||
DNSは、ホスト、サービス、およびその他のリソースが到達可能であることを保証するために、ここで登場します。
|
||||
|
||||
On all hosts, if they require internet connectivity then they must have DNS to be able to resolve those domain names. DNS is an area you could spend Days and Years on learning. I would also say from experience that DNS is mostly the common cause of all errors when it comes to Networking. Not sure if a Network engineer would agree there though.
|
||||
すべてのホストで、それらがインターネット接続を必要とする場合、彼らはこれらのドメイン名を解決することができるようにDNSを持っている必要があります。DNSは、何日も何年もかけて学ぶべき分野です。また、経験上、DNSはネットワークに関わるすべてのエラーの共通原因です。ネットワーク・エンジニアがそう思うかどうかは分かりませんが。
|
||||
|
||||
![](Images/Day23_Networking7.png)
|
||||
|
||||
- DHCP - Dynamic Host Configuration Protocol
|
||||
- DHCP - ダイナミックホストコンフィギュレーションプロトコル
|
||||
|
||||
We have discussed a lot about protocols that are required to make our hosts work, be it accessing the internet or transferring files between each other.
|
||||
これまで、インターネットへのアクセスやファイル転送など、ホストを動作させるために必要なプロトコルについて、たくさん説明してきました。
|
||||
|
||||
There are 4 things that we need on every host for it to be able to achieve both of those tasks.
|
||||
これらのタスクを達成するために、すべてのホストに必要なものが4つあります。
|
||||
|
||||
- IP Address
|
||||
- Subnet Mask
|
||||
- Default Gateway
|
||||
- DNS
|
||||
- IPアドレス
|
||||
- サブネットマスク
|
||||
- デフォルトゲートウェイ
|
||||
- DNS
|
||||
|
||||
We have covered IP address being a unique address for your host on the network it resides, we can think of this as our house number.
|
||||
IPアドレスは、ホストが存在するネットワーク上の一意のアドレスであり、私たちの家の番号のように考えることができます。
|
||||
|
||||
Subnet mask we will cover shortly, but you can think of this as post code or zip code.
|
||||
サブネットマスクについては、後ほど説明しますが、郵便番号のようなものだと考えてください。
|
||||
|
||||
Default gateway is the IP of our router generally on our network providing us with that Layer 3 connectivity. You could think of this as the single road that allows us out of our street.
|
||||
デフォルトゲートウェイは、レイヤー3接続を提供するネットワーク上のルーターのIPです。これは、道路から外に出るための一本道と考えることができます。
|
||||
|
||||
Then we have DNS as we just covered to help us convert complicated public IP addresses to more suitable and rememberable domain names. Maybe we can think of this as the giant sorting office to make sure we get the right post.
|
||||
DNSは、複雑なパブリックIPアドレスを、より適切で覚えやすいドメイン名に変換するためのものです。これは、正しい郵便物を受け取るための巨大な仕分け局と考えることができるかもしれません。
|
||||
|
||||
As I said each host requires these 4 things, if you have 1000 or 10,000 hosts then that is going to take you a very long time to determine each one of these individually. This is where DHCP comes in and allows you to determine a scope for your network and then this protocol will distribute to all available hosts in your network.
|
||||
各ホストにはこの4つが必要ですが、もし1000台や1万台のホストがある場合、それぞれを個別に決定するには非常に長い時間がかかります。そこでDHCPが登場し、ネットワークのスコープを決定し、このプロトコルがネットワーク内の利用可能なすべてのホストに配布されるようになります。
|
||||
|
||||
Another example, you head into a coffee shop, grab a coffee and sit down with your laptop or your phone lets call that your host. You connect your host to the coffee shop wifi and you gain access to the internet, messages and mail start pinging through and you can navigate web pages and social media. When you connected to the coffee shop wifi your machine would have picked up a DHCP address either from a dedicated DHCP server or most likely from the router also handling DHCP.
|
||||
別の例として、あなたはコーヒーショップに向かい、コーヒーを飲んで、ラップトップや携帯電話を持って座り、それをあなたのホストと呼ぶことができます。コーヒーショップの無線LANにホストを接続すると、インターネットにアクセスできるようになり、メッセージやメールがPing送信され、Webページやソーシャルメディアを操作できるようになります。コーヒーショップの無線LANに接続すると、あなたのマシンは、専用のDHCPサーバから、または最も可能性の高いルータからもDHCPを処理するDHCPアドレスを拾っただろう。
|
||||
|
||||
![](Images/Day23_Networking8.png)
|
||||
|
||||
### Subnetting
|
||||
### サブネット
|
||||
|
||||
A subnet is a logical subdivision of an IP network.
|
||||
サブネットは、IP ネットワークを論理的に細分化したものです。
|
||||
|
||||
Subnets break large networks into smaller, more manageable networks that run more efficiently.
|
||||
サブネットは、大規模なネットワークを、より効率的に動作する、より小さな、管理しやすいネットワークに分割します。
|
||||
|
||||
Each subnet is a logical subdivision of the bigger network. Connected devices with enough subnet share common IP address identifier, enabling them to communicate with each other.
|
||||
各サブネットは、より大きなネットワークの論理的な小区画です。十分なサブネットに接続されたデバイスは、共通のIPアドレス識別子を共有し、互いに通信できるようになります。
|
||||
|
||||
Routers manage communication between subnets.
|
||||
ルーターは、サブネット間の通信を管理します。
|
||||
|
||||
The size of a subnet depends on the connectivity requirements and the network technology used.
|
||||
サブネットのサイズは、接続要件と使用するネットワーク技術に依存します。
|
||||
|
||||
An organisation is responsible for determining its number and size of the subnets within the limits of address space
|
||||
available, and the details remain local to that organisation. Subnets can also be segmented into even smaller subnets for things like Point to Point links, or for sub networks supporting a few devices.
|
||||
サブネットのサイズは、接続要件と使用するネットワーク技術に依存します。
|
||||
サブネットのサイズと数は、接続要件と使用するネットワーク技術によって異なります。サブネットは、Point to Pointリンクや、少数のデバイスをサポートするサブネットワークなどのために、さらに小さなサブネットにセグメント化することも可能です。
|
||||
|
||||
Among other advantages, segmenting large
|
||||
networks into subnets enables IP address
|
||||
reallocation and relieves network congestion, streamlining, network communication and efficiency.
|
||||
特に、大規模なネットワークをサブネットに分割することで
|
||||
サブネットに分割することで、IPアドレスの再割り当てが可能になり
|
||||
を再割り当てし、ネットワークの混雑を緩和し、ネットワークの通信を合理化し、効率化することができます。
|
||||
|
||||
Subnets can also improve network security.
|
||||
If a section of a network is compromised, it can be quarantined, making it difficult for bad actors to move around the larger network.
|
||||
また、サブネットはネットワークの安全性を向上させることができます。
|
||||
ネットワークの一部が侵害された場合、その部分を隔離することができ、悪質な業者が大規模なネットワークを動き回ることを困難にすることができます。
|
||||
|
||||
![](Images/Day23_Networking9.png)
|
||||
|
||||
|
||||
## Resources
|
||||
## リソース
|
||||
|
||||
- [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
|
||||
- [Practical Networking](http://www.practicalnetworking.net/)
|
||||
|
||||
See you on [Day 24](day24.md)
|
||||
[24日目](day24.md)でお会いしましょう。
|
||||
|
||||
|
||||
|
173
ja/Days/day24.md
173
ja/Days/day24.md
@ -1,145 +1,146 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Network Automation - Day 24'
|
||||
title: '#90DaysOfDevOps - ネットワーク・オートメーション - 24日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Network Automation
|
||||
description: 90DaysOfDevOps - ネットワーク・オートメーション
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048805
|
||||
---
|
||||
## Network Automation
|
||||
## ネットワーク・オートメーション
|
||||
|
||||
### Basics of network automation
|
||||
### ネットワーク・オートメーションの基本
|
||||
|
||||
Primary drivers for Network Automation
|
||||
- Achieve Agility
|
||||
- Reduce Cost
|
||||
- Eliminate Errors
|
||||
- Ensure Compliance
|
||||
- Centralised Management
|
||||
ネットワーク・オートメーションの主なドライバー:
|
||||
|
||||
The automation adoption process is specific to each business. There's no one size fits all when it comes to deploying automation, the ability to identify and embrace the approach that works best for your organisation is critical in advancing towards maintaining or creating a more agile environment, the focus should always be on business value and end-user experience. (We said something similar right at the start in regards to the whole of DevOps and the culture change and the automated process that this brings)
|
||||
- アジリティの実現
|
||||
- コスト削減
|
||||
- エラーの排除
|
||||
- コンプライアンスの確保
|
||||
- 集中管理
|
||||
|
||||
To break this down you would need to identify how the task or process that you're trying to automate is going to achieve and improve the end-user experience or business value whilst following a step-by-step systematic approach.
|
||||
自動化の導入プロセスは、各ビジネスに特有のものです。よりアジャイルな環境を維持・創造するためには、組織に最適なアプローチを特定し、採用することが重要です。(私たちは、DevOpsの全体像、文化の変化、そしてこれがもたらす自動化されたプロセスに関して、冒頭で同じようなことを述べました)
|
||||
|
||||
"If you don't know where you are going, any road will take you there."
|
||||
これを分解すると、自動化しようとしているタスクやプロセスが、ステップバイステップの体系的なアプローチに従いながら、どのようにエンドユーザー・エクスペリエンスやビジネス価値を達成・向上させようとしているのかを特定する必要があるのです。
|
||||
|
||||
Having a framework or design structure that you're trying to achieve knowing what your end goal is and then working step by step towards achieving that goal measuring the automation success at various stages based on the business outcomes.
|
||||
「もし、あなたがどこに行くのか分からなければ、どんな道でもそこに連れて行ってくれるでしょう。
|
||||
|
||||
Build concepts modelled around existing applications there's no need to design the concepts around automation in a bubble because they need to be applied to your application, your service, your infrastructure, so begin to build the concepts and model them around your existing infrastructure, you're existing applications.
|
||||
最終的な目標を知り、その目標達成に向けて一歩一歩作業を進めるためのフレームワークや設計構造を持ち、ビジネスの成果に基づいて様々な段階での自動化の成功を測定します。
|
||||
|
||||
### Approach to Networking Automation
|
||||
既存のアプリケーションをモデル化したコンセプトを構築する自動化に関するコンセプトをバブルの中で設計する必要はない。なぜなら、それはアプリケーション、サービス、インフラストラクチャに適用する必要があるからです。
|
||||
|
||||
We should identify the tasks and perform a discovery on network change requests so that you have the most common issues and problems to automate a solution to.
|
||||
### ネットワーク自動化の考え方
|
||||
|
||||
- Make a list of all the change requests and workflows that are currently being addressed manually.
|
||||
- Determine the most common, time-consuming and error-prone activities.
|
||||
- Prioritise the requests by taking a business-driven approach.
|
||||
- This is the framework for building an automation process, what must be automated and what must not.
|
||||
タスクを特定し、ネットワークの変更要求に関するディスカバリーを行い、最も一般的な問題やソリューションを自動化するための問題を把握する必要があります。
|
||||
|
||||
We should then divide tasks and analyse how different network functions work and interact with each other.
|
||||
- 現在、手動で対応しているすべての変更要求とワークフローのリストを作成します。
|
||||
- 最も一般的で、時間がかかり、エラーを起こしやすい作業を決定します。
|
||||
- ビジネス主導のアプローチで、リクエストに優先順位をつけます。
|
||||
- これは、自動化プロセスを構築するためのフレームワークであり、何が自動化されなければならず、何が自動化されてはならないか、ということです。
|
||||
|
||||
- Infrastructure/Network team receives change tickets at multiple layers to deploy applications.
|
||||
- Based on Network services, divide them into different areas and understand how they interact with each other.
|
||||
- Application Optimisation
|
||||
- ADC (Application Delivery Controller)
|
||||
- Firewall
|
||||
- DDI (DNS, DHCP, IPAM etc)
|
||||
- Routing
|
||||
- Others
|
||||
- Identify various dependencies to address business and cultural differences and bring in cross-team collaboration.
|
||||
そして、タスクを分割し、異なるネットワーク機能がどのように機能し、互いに影響し合っているかを分析する必要があります。
|
||||
|
||||
Reusable policies, define and simplify reusable service tasks, processes and input/outputs.
|
||||
- インフラ/ネットワークチームは、アプリケーションを展開するために複数のレイヤーで変更チケットを受け取ります。
|
||||
- ネットワークサービスに基づいて、それらを異なる領域に分割し、それらがどのように相互作用するかを理解します。
|
||||
- アプリケーションの最適化
|
||||
- ADC (アプリケーションデリバリーコントローラー)
|
||||
- ファイアウォール
|
||||
- DDI (DNS、DHCP、IPAMなど)
|
||||
- ルーティング
|
||||
- その他
|
||||
- ビジネスや文化の違いに対応し、チーム間のコラボレーションを実現するために、さまざまな依存関係を特定します。
|
||||
|
||||
- Define offerings for various services, processes and input/outputs.
|
||||
- Simplifying the deployment process will reduce the time to market for both new and existing workloads.
|
||||
- Once you have a standard process, it can be sequenced and aligned to individual requests for a multi-threaded approach and delivery.
|
||||
再利用可能なポリシー、再利用可能なサービスタスク、プロセス、インプット/アウトプットを定義し、簡素化する。
|
||||
|
||||
Combine the policies with business-specific activities. How does implementing this policy help the business? Saves time? Saves Money? Provides better business outcome?
|
||||
- 様々なサービス、プロセス、インプット/アウトプットのオファリングを定義する。
|
||||
- 導入プロセスを簡素化することで、新規および既存のワークロードの市場投入までの時間を短縮する。
|
||||
- 標準的なプロセスがあれば、マルチスレッドなアプローチとデリバリーのために、個々のリクエストに順次対応させることができる。
|
||||
|
||||
- Ensure that service tasks are interoperable.
|
||||
- Associate the incremental service tasks so that they align to create business services.
|
||||
- Allow for the flexibility to associate and re-associate service tasks on demand.
|
||||
- Deploy Self-Service capabilities and pave the way for improved operational efficiency.
|
||||
- Allow for the multiple technology skillsets to continue to contribute with oversight and compliance.
|
||||
ポリシーとビジネス特有のアクティビティを組み合わせる。このポリシーを実行することで、ビジネスにどのような効果があるのでしょうか?時間の節約?お金の節約になりますか?より良いビジネス成果をもたらすか?
|
||||
|
||||
**Iterate** on the policies and process, adding and improving while maintaining availability and service.
|
||||
- サービスタスクが相互運用可能であることを確認する。
|
||||
- ビジネスサービスを作成するために、インクリメンタルサービスタスクを関連付けます。
|
||||
- 必要に応じて、サービスタスクの関連付けや再関連付けを柔軟に行えるようにします。
|
||||
- セルフサービス機能を導入し、運用効率を向上させます。
|
||||
- 複数のテクノロジー・スキルセットが、監視とコンプライアンスに貢献し続けることができるようにします。
|
||||
|
||||
- Start small by automating existing tasks.
|
||||
- Get familiar with the automation process, so that you can identify other areas that can benefit from automation.
|
||||
- iterate your automation initiatives, adding agility incrementally while maintaining the required availability.
|
||||
- Taking an incremental approach paves the way for success!
|
||||
可用性とサービスを維持しながら、ポリシーとプロセスを追加・改善し、**反復**します。
|
||||
|
||||
Orchestrate the network service!
|
||||
- 既存のタスクを自動化することから小さく始めます
|
||||
- 自動化プロセスに慣れることで、自動化の恩恵を受けられる他の分野を特定できるようにします。
|
||||
- 自動化の取り組みを繰り返し、必要な可用性を維持しながら、少しずつ敏捷性を高めていきます。
|
||||
- 段階的なアプローチをとることで、成功への道が開かれます。
|
||||
|
||||
- Automation of the deployment process is required to deliver applications rapidly.
|
||||
- Creating an agile service environment requires different elements to be managed across technology skillsets.
|
||||
- Prepare for an end to end orchestration that provides for control over automation and the order of deployments.
|
||||
ネットワークサービスのオーケストレーション
|
||||
|
||||
## Network Automation Tools
|
||||
- アプリケーションを迅速に提供するためには、デプロイメントプロセスの自動化が必要です。
|
||||
- アジャイルなサービス環境を構築するには、技術的なスキルセットを超えてさまざまな要素を管理する必要があります。
|
||||
- 自動化とデプロイの順番をコントロールするために、エンド・ツー・エンドのオーケストレーションの準備をしましょう。
|
||||
|
||||
The good news here is that for the most part, the tools we use here for Network automation are generally the same that we will use for other areas of automation or what we have already covered so far or what we will cover in future sessions.
|
||||
## ネットワーク・オートメーション・ツール
|
||||
|
||||
Operating System - As I have throughout this challenge, I am focusing on doing most of my learning with a Linux OS, those reasons were given in the Linux section but almost all of the tooling that we will touch albeit cross-OS platform maybe today they all started as Linux based applications or tools, to begin with.
|
||||
良いニュースとしては、ネットワークの自動化に使用するツールは、他の自動化の分野や、これまでに取り上げたもの、今後のセッションで取り上げるものと概ね同じであるということです。
|
||||
|
||||
Integrated Development Environment (IDE) - Again not much to say here other than throughout I would suggest Visual Studio Code as your IDE, based on the extensive plugins that are available for so many different languages.
|
||||
オペレーティング・システム - このチャレンジを通して、私はLinux OSで学習のほとんどを行うことに集中しています。その理由はLinuxのセクションで述べましたが、クロスOSプラットフォームとはいえ、今日触れるツールのほとんどすべては、そもそもLinuxベースのアプリケーションまたはツールから始まっています。
|
||||
|
||||
Configuration Management - We have not got to the Configuration management section yet, but it is very clear that Ansible is a favourite in this area for managing and automating configurations. Ansible is written in Python but you do not need to know Python.
|
||||
|
||||
- Agentless
|
||||
- Only requires SSH
|
||||
- Large Support Community
|
||||
- Lots of Network Modules
|
||||
- Push only model
|
||||
- Configured with YAML
|
||||
- Open Source!
|
||||
統合開発環境(IDE) - ここでも、IDEとしてVisual Studio Codeをお勧めする以外、あまり言うことはありません。
|
||||
|
||||
[Link to Ansible Network Modules](https://docs.ansible.com/ansible/2.9/modules/list_of_network_modules.html)
|
||||
構成管理 - 構成管理のセクションはまだですが、構成の管理と自動化のためにAnsibleがこの分野で人気があることは明らかです。AnsibleはPythonで書かれていますが、Pythonの知識は必要ありません。
|
||||
|
||||
We will also touch on **Ansible Tower** in the configuration management section, see this as the GUI front end for Ansible.
|
||||
- エージェントレス
|
||||
- SSHのみ必要
|
||||
- 大規模なサポートコミュニティ
|
||||
- 豊富なネットワークモジュール
|
||||
- プッシュ型
|
||||
- YAMLで設定
|
||||
- オープンソース
|
||||
|
||||
CI/CD - Again we will cover more about the concepts and tooling around this but it's important to at least mention here as this spans not only networking but all provisioning of service and platform.
|
||||
[Ansibleネットワークモジュールへのリンク](https://docs.ansible.com/ansible/2.9/modules/list_of_network_modules.html)
|
||||
|
||||
In particular, Jenkins provides or seems to be a popular tool for Network Automation.
|
||||
また、構成管理セクションで**Ansible Tower**について触れますが、これはAnsibleのGUIフロントエンドとして見てください。
|
||||
|
||||
- Monitors git repository for changes and then initiates them.
|
||||
CI/CD - CI/CDのコンセプトとツールについてはまた後ほど詳しく説明しますが、ネットワークだけでなく、サービスやプラットフォームのプロビジョニング全般に渡るものなので、少なくともここで触れておくことは重要です。
|
||||
|
||||
Version Control - Again something we will dive deeper into later on.
|
||||
特に、Jenkins はネットワークの自動化のためのツールを提供しており、また、人気のあるツールのようです。
|
||||
|
||||
- Git provides version control of your code on your local device - Cross-Platform
|
||||
- GitHub, GitLab, BitBucket etc are online websites where you define your repositories and upload your code.
|
||||
- gitリポジトリを監視して、変更を開始します。
|
||||
|
||||
Language | Scripting - Something we have not covered here is Python as a language, I decided to dive into Go instead as the programming language based on my circumstances, I would say that it was a close call between Golang and Python and Python it seems to be the winner for Network Automation.
|
||||
バージョン管理 - これも後ほど詳しく説明します。
|
||||
|
||||
- Nornir is something to mention here, an automation framework written in Python. This seems to take the role of Ansible but specifically around Network Automation. [Nornir documentation](https://nornir.readthedocs.io/en/latest/)
|
||||
- Gitは、あなたのローカルデバイス上でコードのバージョン管理を提供します - クロスプラットフォーム
|
||||
- GitHub, GitLab, BitBucket などは、リポジトリを定義し、コードをアップロードするオンラインウェブサイトです。
|
||||
|
||||
Analyse APIs - Postman is a great tool for analysing RESTful APIs. Helps to build, test and modify APIs.
|
||||
GolangとPythonは接戦で、Pythonがネットワークオートメーションの勝者であるように思います。
|
||||
|
||||
- POST >>> To create resources objects.
|
||||
- GET >>> To retrieve a resources.
|
||||
- PUT >>> To create or replace the resources.
|
||||
- PATCH >>> To create or update the resources object.
|
||||
- Delete >>> To delete a resources
|
||||
- ここで特筆すべきはNornirで、Pythonで書かれた自動化フレームワークです。これはAnsibleの役割を担っているようですが、特にネットワークオートメーションに特化しているようです。[Nornirのドキュメント](https://nornir.readthedocs.io/en/latest/)
|
||||
|
||||
[Postman tool Download](https://www.postman.com/downloads/)
|
||||
APIの分析 - Postmanは、RESTfulなAPIを分析するための素晴らしいツールです。APIを構築、テスト、修正するのに役立ちます。
|
||||
|
||||
### Other tools to mention
|
||||
- POST >> リソースオブジェクトを作成する。
|
||||
- GET >> リソースを取得する。
|
||||
- PUT >> リソースを作成または置き換えます。
|
||||
- PATCH >> リソースオブジェクトを作成または更新します。
|
||||
- Delete >> リソースを削除します。
|
||||
|
||||
[Postmanダウンロード](https://www.postman.com/downloads/)
|
||||
|
||||
### その他特記すべきツール
|
||||
|
||||
[Cisco NSO (Network Services Orchestrator)](https://www.cisco.com/c/en/us/products/cloud-systems-management/network-services-orchestrator/index.html)
|
||||
|
||||
[NetYCE - Simplify Network Automation](https://netyce.com/)
|
||||
|
||||
[Network Test Automation](https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/)
|
||||
[ネットワークテスト自動化](https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/)
|
||||
|
||||
Over the next 3 days, I am planning to get more hands-on around some of the things we have covered and put some work in around Python and Network automation.
|
||||
この3日間で、これまでカバーしてきたことをさらに実践し、Pythonとネットワークの自動化に関する作業を行う予定です。
|
||||
|
||||
We have nowhere near covered all of the networking topics so far but wanted to make this broad enough to follow along and still keep learning from the resources I am adding below.
|
||||
私たちはこれまでネットワークのトピックをすべてカバーすることはできませんでしたが、フォローしながらも、以下に追加するリソースから学び続けることができるように、これを十分に広くしたいと思いました。
|
||||
|
||||
## Resources
|
||||
## リソース
|
||||
|
||||
- [3 Necessary Skills for Network Automation](https://www.youtube.com/watch?v=KhiJ7Fu9kKA&list=WL&index=122&t=89s)
|
||||
- [Computer Networking full course](https://www.youtube.com/watch?v=IPvYjXCsTg8)
|
||||
- [Practical Networking](http://www.practicalnetworking.net/)
|
||||
- [Python Network Automation](https://www.youtube.com/watch?v=xKPzLplPECU&list=WL&index=126)
|
||||
|
||||
See you on [Day 25](day25.md)
|
||||
[25日目](day25.md)でお会いしましょう。
|
||||
|
130
ja/Days/day25.md
130
ja/Days/day25.md
@ -1,168 +1,168 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Python for Network Automation - Day 25'
|
||||
title: '#90DaysOfDevOps - Pythonによるネットワーク自動化 - 25日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Python for Network Automation
|
||||
description: 90DaysOfDevOps - Pythonによるネットワーク自動化
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1049038
|
||||
---
|
||||
## Python for Network Automation
|
||||
## Pythonによるネットワーク自動化
|
||||
|
||||
Python is the standard language used for automated network operations.
|
||||
Pythonはネットワーク運用の自動化に使われる標準的な言語です。
|
||||
|
||||
Whilst it is not only for network automation it seems to be everywhere when you are looking for resources and as previously mentioned if it's not Python then it's generally Ansible which is written also in Python.
|
||||
Pythonはネットワークの自動化だけではありませんが、リソースを探しているときはどこにでもあるように見えますし、前述のようにPythonでない場合は、一般的に同じくPythonで書かれたAnsibleです。
|
||||
|
||||
I think I have mentioned this already but during the "Learn a programming language" section I chose Golang over Python for reasons around my company are developing in Go so that was a good reason for me to learn but if that was not the case then Python would have taken that time.
|
||||
これはすでに述べたと思いますが、「プログラミング言語を学ぶ」のセクションで、私はPythonではなくGolangを選びました。私の会社がGoで開発しているので、学ぶのに良い理由でしたが、そうでなければ、Pythonにその時間を取られていたことでしょう。
|
||||
|
||||
- Readability and ease of use - It seems that Python seems to just make sense. There doesn't seem to be the requirements around `{}` in the code to start and end blocks. Couple this with a strong IDE like VS Code you have a pretty easy start when wanting to run some python code.
|
||||
- 読みやすさと使いやすさ - Pythonは理にかなっているように思えます。ブロックの開始と終了のために、コードに `{}` のような要件はないようです。VS Codeのような強力なIDEと組み合わせると、Pythonのコードを実行したいときにかなり簡単に始めることができます。
|
||||
|
||||
Pycharm might be another IDE worth mentioning here.
|
||||
Pycharmは、ここで言及する価値のある別のIDEかもしれません。
|
||||
|
||||
- Libraries - The extensibility of Python is the real gold mine here, I mentioned before that this is not just for Network Automation but in fact, there are libraries plenty for all sorts of devices and configurations. You can see the vast amount here [PyPi](https://pypi.python.org/pypi)
|
||||
- ライブラリ - Pythonの拡張性は、ここでの本当の金鉱です。私は、これがネットワークオートメーションのためだけではないことを前に述べましたが、実際には、あらゆる種類のデバイスと構成のための多くのライブラリが存在します。PyPi](https://pypi.python.org/pypi)でその膨大な量を見ることができます。
|
||||
|
||||
When you want to download the library to your workstation, then you use a tool called `pip` to connect to PyPI and download it locally. Network vendors such as Cisco, Juniper, and Arista developed libraries to facilitate access to their devices.
|
||||
ライブラリをワークステーションにダウンロードしたい場合は、`pip`というツールを使ってPyPIに接続し、ローカルにダウンロードします。Cisco、Juniper、Aristaのようなネットワークベンダーは、彼らのデバイスへのアクセスを容易にするためにライブラリを開発しました。
|
||||
|
||||
- Powerful & Efficient - Remember during the Go days I went through the "Hello World" scenario and we went through I think 6 lines of code? In Python it is
|
||||
- パワフルで効率的 - Goの時代に "Hello World "のシナリオで、確か6行のコードを書いたのを覚えていますか?Pythonでは、次のようになります。
|
||||
|
||||
```
|
||||
print('hello world')
|
||||
```
|
||||
|
||||
Put all of the above points together and it should be easy to see why Python is generally mentioned as the de-facto tool when working on automating.
|
||||
上記の点をまとめると、なぜPythonが自動化に取り組む際のデファクト・ツールとして一般的に言及されるのか、容易に理解できるはずです。
|
||||
|
||||
I think it's important to note that it's possible that several years back there were scripts that might have interacted with your network devices to maybe automate the backup of configuration or to gather logs and other insights into your devices. The automation we are talking about here is a little different and that's because the overall networking landscape has also changed to suit this way of thinking better and enabled more automation.
|
||||
数年前までは、ネットワークデバイスと対話し、設定のバックアップを自動化したり、デバイスに関するログやその他の洞察を収集したりするスクリプトがあったかもしれない、ということは重要だと思います。私達がここで話している自動化は少し違います。それは全体的なネットワーク環境もこの考え方に合うように変化し、より多くの自動化が可能になったからです。
|
||||
|
||||
- Software-Defined Network - SDN Controllers take the responsibility of delivering the control plane configuration to all devices on the network, meaning just a single point of contact for any network changes, no longer having to telnet or SSH into every device and also relying on humans to do this which has a repeatable chance of failure or misconfiguration.
|
||||
- Software-Defined Network - SDN コントローラはネットワーク上の全てのデバイスにコントロールプレーンのコンフィグレーションを提供するという責任を負います。
|
||||
|
||||
- High-Level Orchestration - Go up a level from those SDN controllers and this allows for orchestration of service levels then there is the integration of this orchestration layer into your platforms of choice, VMware, Kubernetes, Public Clouds etc.
|
||||
- ハイレベルなオーケストレーション - SDN コントローラから一段上がって、サービスレベルのオーケストレーションが可能になり、このオーケストレーションレイヤーを VMware、Kubernetes、パブリッククラウド等、あなたの選んだプラットフォームに統合することができるようになります。
|
||||
|
||||
- Policy-based management - What do you want to have? What is the desired state? You describe this and the system has all the details on how to figure it out to become the desired state.
|
||||
- ポリシーベースの管理 - どのような状態にしたいのか?どのような状態が望ましいのか?これを記述すると、システムはそれをどのように把握し、望ましい状態にするのか、すべての詳細を持っています。
|
||||
|
||||
## Setting up the lab environment
|
||||
## ラボ環境のセットアップ
|
||||
|
||||
Not everyone has access to physical routers, switches and other networking devices.
|
||||
誰もが物理的なルータやスイッチ、その他のネットワーク機器にアクセスできるわけではありません。
|
||||
|
||||
I wanted to make it possible for us to look at some of the tooling pre-mentioned but also get hands-on and learn how to automate the configuration of our networks.
|
||||
私は、前述のツールのいくつかを見るだけでなく、実際に手を動かして、ネットワークの設定を自動化する方法を学ぶことができるようにしたいと思いました。
|
||||
|
||||
When it comes to options there are a few that we can choose from.
|
||||
オプションとして、以下のようなものがあります。
|
||||
|
||||
- [GNS3 VM](https://www.gns3.com/software/download-vm)
|
||||
- [Eve-ng](https://www.eve-ng.net/)
|
||||
- [Unimus](https://unimus.net/) Not a lab environment but an interesting concept.
|
||||
- [Unimus](https://unimus.net/) ラボ環境ではありませんが、興味深いコンセプトです。
|
||||
|
||||
We will build our lab out using [Eve-ng](https://www.eve-ng.net/) as mentioned before you can use a physical device but to be honest a virtual environment means that we can have a sandbox environment to test many different scenarios. Plus being able to play with different devices and topologies might be of interest.
|
||||
[Eve-ng](https://www.eve-ng.net/)を使ってラボを構築します。前述のように物理デバイスを使うこともできますが、正直なところ、仮想環境は、さまざまなシナリオをテストするサンドボックス環境を提供することを意味します。さらに、さまざまなデバイスやトポロジーで遊ぶことができるのも魅力的です。
|
||||
|
||||
We are going to do everything on EVE-NG with the community edition.
|
||||
EVE-NGでは、コミュニティ版ですべてを行う予定です。
|
||||
|
||||
### Getting started
|
||||
### はじめに
|
||||
|
||||
The community edition comes in ISO and OVF formats for [download](https://www.eve-ng.net/index.php/download/)
|
||||
コミュニティ版にはISOとOVFのフォーマットがあり、[ダウンロード](https://www.eve-ng.net/index.php/download/)することができます。
|
||||
|
||||
We will be using the OVF download but with the ISO there is the option to build out on a bare metal server without the need of a hypervisor.
|
||||
今回はOVFを使用しますが、ISOではハイパーバイザーを使用せずにベアメタルサーバーでビルドアウトすることも可能です。
|
||||
|
||||
![](Images/Day25_Networking1.png)
|
||||
このチュートリアルは、以下のような内容になっています。
|
||||
|
||||
For our walkthrough, we will be using VMware Workstation as I have a license via my vExpert but you can equally use VMware Player or any of the other options mentioned in the [documentation](https://www.eve-ng.net/index.php/documentation/installation/system-requirement/)Unfortunately we cannot use our previously used Virtual box!
|
||||
このウォークスルーでは、私はvExpertのライセンスを持っているので、VMware Workstationを使用しますが、VMware Playerや[ドキュメント](https://www.eve-ng.net/index.php/documentation/installation/system-requirement/)に記載されている他のオプションも同様に使用できます。残念ながら、以前使用したVirtual boxは使用できません!
|
||||
|
||||
This is also where I had an issue with GNS3 with Virtual Box even though supported.
|
||||
GNS3がサポートされていても、Virtual Boxで問題があったのはここでも同じです。
|
||||
|
||||
[Download VMware Workstation Player - FREE](https://www.vmware.com/uk/products/workstation-player.html)
|
||||
|
||||
[VMware Workstation PRO](https://www.vmware.com/uk/products/workstation-pro.html) Also noted that there is an evaluation period for free!
|
||||
|
||||
### Installation on VMware Workstation PRO
|
||||
### VMware Workstation PROへのインストール
|
||||
|
||||
Now we have our hypervisor software downloaded and installed, and we have the EVE-NG OVF downloaded. If you are using VMware Player please let me know if this process is the same.
|
||||
ハイパーバイザーソフトウェアのダウンロードとインストール、そしてEVE-NG OVFのダウンロードが完了しました。VMware Playerをお使いの方は、この手順が同じかどうか教えてください。
|
||||
|
||||
We are now ready to get things configured.
|
||||
これで、設定を行う準備が整いました。
|
||||
|
||||
Open VMware Workstation and then select `file` and `open`
|
||||
VMware Workstationを起動し、`ファイル`と`開く`を選択します。
|
||||
|
||||
![](Images/Day25_Networking2.png)
|
||||
|
||||
When you download the EVE-NG OVF Image it is going to be within a compressed file. Extract the contents out into its folder so it looks like.
|
||||
EVE-NG OVF Imageをダウンロードすると、圧縮されたファイルに入っているはずです。そのフォルダに中身を取り出すと、以下のようになります。
|
||||
|
||||
![](Images/Day25_Networking3.png)
|
||||
|
||||
Navigate to the location that you downloaded the EVE-NG OVF image to and begin the import.
|
||||
EVE-NG OVF イメージをダウンロードした場所に移動し、インポートを開始します。
|
||||
|
||||
Give it a recognisable name and store the virtual machine somewhere on your system.
|
||||
わかりやすい名前を付けて、仮想マシンをシステムのどこかに保存してください。
|
||||
|
||||
![](Images/Day25_Networking4.png)
|
||||
|
||||
When the import is complete increase the number of processors to 4 and the memory allocated to 8 GB. (This should be the case after import with the latest version if not then edit VM settings)
|
||||
インポートが完了したら、プロセッサの数を 4 に、割り当てられたメモリを 8GB に増やします。(最新バージョンでインポートした場合は、このようになるはずです。)
|
||||
|
||||
Also, make sure the Virtualise Intel VT-x/EPT or AMD-V/RVI checkbox is enabled. This option instructs VMware workstation to pass the virtualisation flags to the guest OS (nested virtualisation) This was the issue I was having with GNS3 with Virtual Box even though my CPU allows this.
|
||||
また、Virtualise Intel VT-x/EPT or AMD-V/RVIチェックボックスが有効であることを確認してください。このオプションは、VMware Workstationに仮想化フラグをゲストOSに渡すように指示します(ネストされた仮想化)これは、私のCPUがこれを可能にするにもかかわらず、Virtual BoxでGNS3が抱えていた問題でした。
|
||||
|
||||
![](Images/Day25_Networking5.png)
|
||||
|
||||
### Power on & Access
|
||||
### パワーオン&アクセス
|
||||
|
||||
Sidenote & Rabbit hole: Remember I mentioned that this would not work with VirtualBox! Well yeah had the same issue with VMware Workstation and EVE-NG but it was not the fault of the virtualisation platform!
|
||||
補足&うさぎの穴。VirtualBoxでは動作しないと書いたのを覚えていますか?VMware WorkstationとEVE-NGで同じ問題が発生しましたが、仮想化プラットフォームのせいではありませんでした!
|
||||
|
||||
I have WSL2 running on my Windows Machine and this seems to remove the capability of being able to run anything nested inside of your environment. I am confused as to why the Ubuntu VM does run as it seems to take out the Intel VT-d virtualisation aspect of the CPU when using WSL2.
|
||||
私はWindowsマシンでWSL2を走らせていますが、これはあなたの環境の中でネストされたものを走らせる能力を取り除くようです。WSL2 を使用すると、CPU の Intel VT-d 仮想化機能が削除されるようなので、Ubuntu VM が実行されるのはなぜか、混乱しています。
|
||||
|
||||
To resolve this we can run the following command on our Windows machine and reboot the system, note that whilst this is off then you will not be able to use WSL2.
|
||||
これを解決するには、Windowsマシンで次のコマンドを実行し、システムを再起動します。
|
||||
|
||||
`bcdedit /set hypervisorlaunchtype off`
|
||||
|
||||
When you want to go back and use WSL2 then you will need to run this command and reboot.
|
||||
WSL2に戻りたい場合は、このコマンドを実行し、再起動する必要があります。
|
||||
|
||||
`bcdedit /set hypervisorlaunchtype auto`
|
||||
|
||||
Both of these commands should be ran as administrator!
|
||||
これらのコマンドは両方とも管理者として実行する必要があります。
|
||||
|
||||
Ok back to the show, You should now have a powered-on machine in VMware Workstation and you should have a prompt looking similar to this.
|
||||
これでVMware Workstationに電源が入り、次のようなプロンプトが表示されるはずです。
|
||||
|
||||
![](Images/Day25_Networking6.png)
|
||||
|
||||
On the prompt above you can use:
|
||||
上のプロンプトで、あなたは使うことができます。
|
||||
|
||||
username = root
|
||||
password = eve
|
||||
|
||||
You will then be asked to provide the root password again, this will be used to SSH into the host later on.
|
||||
このパスワードは後でホストに SSH 接続するために使用されます。
|
||||
|
||||
We then can change the hostname.
|
||||
これで、ホスト名を変更することができます。
|
||||
|
||||
![](Images/Day25_Networking7.png)
|
||||
|
||||
Next, we define a DNS Domain Name, I have used the one below but I am not sure if this will need to be changed later on.
|
||||
次に、DNS Domain Nameを定義します。私は以下のものを使用しましたが、これは後で変更する必要があるかどうかはわかりません。
|
||||
|
||||
![](Images/Day25_Networking8.png)
|
||||
|
||||
We then configure networking, I am selecting static so that the IP address given will be persistent after reboots.
|
||||
次にネットワークの設定を行いますが、私は与えられたIPアドレスが再起動後も持続するように静的を選択しています。
|
||||
|
||||
![](Images/Day25_Networking9.png)
|
||||
|
||||
The final step, provide a static IP address from a network that is reachable from your workstation.
|
||||
最後のステップでは、ワークステーションから到達可能なネットワークから固定IPアドレスを提供します。
|
||||
|
||||
![](Images/Day25_Networking10.png)
|
||||
|
||||
There are some additional steps here where you will have to provide a subnet mask for your network, default gateway and DNS.
|
||||
ここで、ネットワークのサブネットマスク、デフォルトゲートウェイ、DNSを指定する手順が追加されます。
|
||||
|
||||
Once finished it will reboot, when it is back up you can take your static IP address and put this into your browser.
|
||||
終了すると再起動します。再起動後、固定IPアドレスを取得し、これをブラウザに入力することができます。
|
||||
|
||||
![](Images/Day25_Networking11.png)
|
||||
|
||||
The default username for the GUI is `admin` and the password is `eve` while the default username for SSH is `root` and the password is `eve` but this would have been changed if you changed during the setup.
|
||||
GUIのデフォルトのユーザー名は `admin` でパスワードは `eve` です。SSHのデフォルトのユーザー名は `root` でパスワードは `eve` ですが、セットアップ中に変更した場合は、このユーザー名も変更されているはずです。
|
||||
|
||||
![](Images/Day25_Networking12.png)
|
||||
|
||||
I chose HTML5 for the console vs native as this will open a new tab in your browser when you are navigating through different consoles.
|
||||
コンソールにHTML5を選択したのは、異なるコンソールをナビゲートするときに、ブラウザで新しいタブを開くためです。
|
||||
|
||||
Next up we are going to:
|
||||
次は、次のことを行います。
|
||||
|
||||
- Install the EVE-NG client pack
|
||||
- Load some network images into EVE-NG
|
||||
- Build a Network Topology
|
||||
- Adding Nodes
|
||||
- Connecting Nodes
|
||||
- Start building Python Scripts
|
||||
- Look at telnetlib, Netmiko, Paramiko and Pexpect
|
||||
- EVE-NGクライアントパックをインストールします
|
||||
- EVE-NGにいくつかのネットワークイメージをロードします
|
||||
- ネットワークトポロジーの構築
|
||||
- ノードの追加
|
||||
- ノードの接続
|
||||
- Pythonスクリプトのビルドを開始
|
||||
- telnetlib、Netmiko、Paramiko、Pexpectを見ます
|
||||
|
||||
## Resources
|
||||
## リソース
|
||||
|
||||
- [Free Course: Introduction to EVE-NG](https://www.youtube.com/watch?v=g6B0f_E0NMg)
|
||||
- [EVE-NG - Creating your first lab](https://www.youtube.com/watch?v=9dPWARirtK8)
|
||||
@ -171,4 +171,4 @@ Next up we are going to:
|
||||
- [Practical Networking](http://www.practicalnetworking.net/)
|
||||
- [Python Network Automation](https://www.youtube.com/watch?v=xKPzLplPECU&list=WL&index=126)
|
||||
|
||||
See you on [Day 26](day26.md)
|
||||
[26日目](day26.md)でお会いしましょう。
|
||||
|
@ -1,47 +1,47 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Building our Lab - Day 26'
|
||||
title: '#90DaysOfDevOps - ラボの構築 - 26日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Building our Lab
|
||||
description: 90DaysOfDevOps - ラボの構築
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048762
|
||||
---
|
||||
## Building our Lab
|
||||
## ラボの構築
|
||||
|
||||
We are going to continue our setup of our emulated network using EVE-NG and then hopefully get some devices deployed and start thinking about how we can automate the configuration of these devices. On [Day 25](day25.md) we covered the installation of EVE-NG onto our machine using VMware Workstation.
|
||||
EVE-NGを使用してエミュレートしたネットワークのセットアップを継続し、いくつかのデバイスをデプロイして、これらのデバイスの設定を自動化する方法について考え始めたいと考えています。[Day 25](day25.md) では、VMware Workstation を使用してマシンに EVE-NG をインストールする方法について説明しました。
|
||||
|
||||
### Installing EVE-NG Client
|
||||
### EVE-NG クライアントのインストール
|
||||
|
||||
There is also a client pack that allows us to choose which application is used when we SSH to the devices. It will also set up Wireshark for packet captures between links. You can grab the client pack for your OS (Windows, macOS, Linux).
|
||||
デバイスにSSHするときにどのアプリケーションを使うかを選択できるクライアントパックもあります。また、リンク間のパケットキャプチャのためにWiresharkをセットアップします。お使いのOS(Windows、macOS、Linux)に対応したクライアントパックを入手することができます。
|
||||
|
||||
[EVE-NG Client Download](https://www.eve-ng.net/index.php/download/)
|
||||
|
||||
![](Images/Day26_Networking1.png)
|
||||
|
||||
Quick Tip: If you are using Linux as your client then there is this [client pack](https://github.com/SmartFinn/eve-ng-integration).
|
||||
クイックヒント: クライアントとしてLinuxを使用している場合、この[クライアントパック](https://github.com/SmartFinn/eve-ng-integration)があります。
|
||||
|
||||
The install is a straightforward next,next and I would suggest leaving the defaults.
|
||||
インストールは簡単で、デフォルトのままにしておくことをお勧めします。
|
||||
|
||||
### Obtaining network images
|
||||
### ネットワークイメージの取得
|
||||
|
||||
This step has been a challenge, I have followed some videos that I will link at the end that links to some resources and downloads for our router and switch images whilst telling us how and where to upload them.
|
||||
このステップは挑戦でした、私はいくつかのリソースへのリンクとルータとスイッチの画像をダウンロードしながら、それらをアップロードする方法と場所を教えてくれる最後にリンクするいくつかのビデオに従いました。
|
||||
|
||||
It is important to note that I using everything for education purposes. I would suggest downloading official images from network vendors.
|
||||
これは、私は教育目的のためにすべてを使用していることに注意することが重要です。私は、ネットワークベンダから公式の画像をダウンロードすることをお勧めします。
|
||||
|
||||
[Blog & Links to YouTube videos](https://loopedback.com/2019/11/15/setting-up-eve-ng-for-ccna-ccnp-ccie-level-studies-includes-multiple-vendor-node-support-an-absolutely-amazing-study-tool-to-check-out-asap/)
|
||||
|
||||
[How To Add Cisco VIRL vIOS image to Eve-ng](https://networkhunt.com/how-to-add-cisco-virl-vios-image-to-eve-ng/)
|
||||
|
||||
Overall the steps here are a little complicated and could be much easier but the above blogs and videos walk through the process of adding the images to your EVE-NG box.
|
||||
全体的にこのステップは少し複雑で、もっと簡単にできるかもしれませんが、上記のブログとビデオはEVE-NGボックスにイメージを追加するプロセスを説明しています。
|
||||
|
||||
I used FileZilla to transfer the qcow2 to the VM over SFTP.
|
||||
私はFileZillaを使用して、SFTP経由でqcow2をVMに転送しました。
|
||||
|
||||
For our lab, we need Cisco vIOS L2 (switches) and Cisco vIOS (router)
|
||||
このラボでは、Cisco vIOS L2(スイッチ)とCisco vIOS(ルーター)が必要です。
|
||||
|
||||
### Create a Lab
|
||||
### ラボの作成
|
||||
|
||||
Inside the EVE-NG web interface, we are going to create our new network topology. We will have four switches and one router that will act as our gateway to outside networks.
|
||||
EVE-NGのWebインターフェイス内で、新しいネットワークトポロジーを作成します。4台のスイッチと、外部ネットワークへのゲートウェイとして機能する1台のルータを用意する予定です。
|
||||
|
||||
| Node | IP Address |
|
||||
| ----------- | ----------- |
|
||||
@ -51,50 +51,50 @@ Inside the EVE-NG web interface, we are going to create our new network topology
|
||||
| Switch3 | 10.10.88.113|
|
||||
| Switch4 | 10.10.88.114|
|
||||
|
||||
#### Adding our Nodes to EVE-NG
|
||||
#### EVE-NGにノードを追加する
|
||||
|
||||
When you first log in to EVE-NG you will see a screen like below, we want to start by creating our first lab.
|
||||
EVE-NGに初めてログインすると、以下のような画面が表示されますので、まずは最初のラボを作成してみたいと思います。
|
||||
|
||||
![](Images/Day26_Networking2.png)
|
||||
|
||||
Give your lab a name and the other fields are optional.
|
||||
研究室の名前を入力します。その他の項目は任意です。
|
||||
|
||||
![](Images/Day26_Networking3.png)
|
||||
|
||||
You will be then greeted with a blank canvas to start creating your network. Right-click on your canvas and choose add node.
|
||||
すると、ネットワークの作成を開始するための空白のキャンバスが表示されます。キャンバス上で右クリックし、ノードの追加を選択します。
|
||||
|
||||
From here you will have a long list of node options, If you have followed along above you will have the two in blue shown below and the others are going to be grey and unselectable.
|
||||
ここで、ノードのオプションの長いリストが表示されます。上記で説明した通りなら、下図の青い2つのノードがあり、他のノードはグレーで選択できないようになっています。
|
||||
|
||||
![](Images/Day26_Networking4.png)
|
||||
|
||||
We want to add the following to our lab:
|
||||
ラボに以下を追加したい:
|
||||
|
||||
- 1 x Cisco vIOS Router
|
||||
- 1 x Cisco vIOS Router
|
||||
- 4 x Cisco vIOS Switch
|
||||
|
||||
Run through the simple wizard to add them to your lab and it should look something like this.
|
||||
簡単なウィザードを実行し、ラボに追加すると次のようになります。
|
||||
|
||||
![](Images/Day26_Networking5.png)
|
||||
|
||||
#### Connecting our nodes
|
||||
#### ノードの接続
|
||||
|
||||
We now need to add our connectivity between our routers and switches. We can do this quite easily by hovering over the device and seeing the connection icon as per below and then connecting that to the device we wish to connect to.
|
||||
次に、ルータとスイッチの間の接続を追加する必要があります。デバイスの上にカーソルを置くと、以下のような接続アイコンが表示されるので、それを接続したいデバイスに接続すれば、簡単に接続することができます。
|
||||
|
||||
![](Images/Day26_Networking6.png)
|
||||
|
||||
When you have finished connecting your environment you may also want to add some way to define physical boundaries or locations using boxes or circles which can also be found in the right-click menu. You can also add text which is useful when we want to define our naming or IP addresses in our labs.
|
||||
環境の接続が完了したら、右クリックメニューにあるボックスや円を使用して、物理的な境界や位置を定義する方法を追加することもできます。また、テキストを追加することも可能で、ラボのネーミングやIPアドレスを定義するのに便利です。
|
||||
|
||||
I went ahead and made my lab look like the below.
|
||||
私は、以下のようなラボを作りました。
|
||||
|
||||
![](Images/Day26_Networking7.png)
|
||||
|
||||
You will also notice that the lab above is all powered off, we can start our lab by selecting everything and right-clicking and selecting start selected.
|
||||
また、上のラボはすべて電源が切れていることに気づきます。すべてを選択して右クリックし、選択した状態で起動することで、ラボを開始することができます。
|
||||
|
||||
![](Images/Day26_Networking8.png)
|
||||
|
||||
Once we have our lab up and running you will be able to console into each device and you will notice at this stage they are pretty dumb with no configuration. We can add some configuration to each node by copying or creating your own in each terminal.
|
||||
このラボを立ち上げると、各デバイスにコンソールできるようになります。この段階では、何も設定されておらず、かなり間抜けな状態であることに気づくでしょう。各端末の設定をコピーするか、自分で作成することで、各ノードに設定を追加することができます。
|
||||
|
||||
I will leave my configuration in the Networking folder of the repository for reference.
|
||||
私は参考のため、リポジトリの Networking フォルダに設定を残しておきます。
|
||||
|
||||
| Node | Configuration |
|
||||
| ----------- | ----------- |
|
||||
@ -104,7 +104,7 @@ I will leave my configuration in the Networking folder of the repository for ref
|
||||
| Switch3 | [SW3](Networking/SW3) |
|
||||
| Switch4 | [SW4](Networking/SW4) |
|
||||
|
||||
## Resources
|
||||
## リソース
|
||||
|
||||
- [Free Course: Introduction to EVE-NG](https://www.youtube.com/watch?v=g6B0f_E0NMg)
|
||||
- [EVE-NG - Creating your first lab](https://www.youtube.com/watch?v=9dPWARirtK8)
|
||||
@ -113,8 +113,8 @@ I will leave my configuration in the Networking folder of the repository for ref
|
||||
- [Practical Networking](http://www.practicalnetworking.net/)
|
||||
- [Python Network Automation](https://www.youtube.com/watch?v=xKPzLplPECU&list=WL&index=126)
|
||||
|
||||
Most of the examples I am using here as I am not a Network Engineer have come from this extensive book which is not free but I am using some of the scenarios to help understand Network Automation.
|
||||
私はネットワークエンジニアではないので、ここで使用している例のほとんどは、無料ではありませんが、Network Automationを理解するのに役立つシナリオのいくつかをこの本から引用しています。
|
||||
|
||||
- [Hands-On Enterprise Automation with Python (Book)](https://www.packtpub.com/product/hands-on-enterprise-automation-with-python/9781788998512)
|
||||
|
||||
See you on [Day 27](day27.md)
|
||||
[27日目](day27.md)でお会いしましょう。
|
||||
|
@ -1,31 +1,31 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Getting Hands-On with Python & Network - Day 27'
|
||||
title: '#90DaysOfDevOps - Pythonとネットワークのハンズオン - 27日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Getting Hands-On with Python & Network
|
||||
description: 90DaysOfDevOps - Pythonとネットワークのハンズオン
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048735
|
||||
---
|
||||
## Getting Hands-On with Python & Network
|
||||
## Pythonとネットワークのハンズオン
|
||||
|
||||
In this final section of Networking fundamentals, we are going to cover some automation tasks and tools with our lab environment created on [Day 26](day26.md)
|
||||
ネットワークの基礎の最後のセクションでは、[Day 26](day26.md) で作成したラボ環境を使って、いくつかの自動化タスクとツールをカバーするつもりです。
|
||||
|
||||
We will be using an SSH tunnel to connect to our devices from our client vs telnet. The SSH tunnel created between client and device is encrypted. We also covered SSH in the Linux section on [Day 18](day18.md)
|
||||
クライアントからデバイスに接続するために、SSHトンネルを使用する予定です。クライアントとデバイスの間に作成された SSH トンネルは暗号化されています。SSHについては、[Day18](day18.md)のLinuxセクションでも取り上げました。
|
||||
|
||||
## Access our virtual emulated environment
|
||||
## 仮想エミュレート環境にアクセスする
|
||||
|
||||
For us to interact with our switches we either need a workstation inside the EVE-NG network and you can deploy a Linux box there with Python installed to perform your automation ([Resource for setting up Linux inside EVE-NG](https://www.youtube.com/watch?v=3Qstk3zngrY)) or you can do something like me and define a cloud for access from your workstation.
|
||||
EVE-NGネットワーク内にワークステーションが必要で、そこにPythonをインストールしたLinuxボックスを配置して自動化を行うか([Resource for setting up Linux inside EVE-NG](https://www.youtube.com/watch?v=3Qstk3zngrY)) 、私のようにワークステーションからアクセスするクラウドを定義することができます。
|
||||
|
||||
![](Images/Day27_Networking3.png)
|
||||
|
||||
To do this, we have right-clicked on our canvas and we have selected network and then selected "Management(Cloud0)" this will bridge out to our home network.
|
||||
これを行うには、キャンバスを右クリックして、ネットワークを選択し、「Management(Cloud0)」を選択して、ホームネットワークに橋渡しします。
|
||||
|
||||
![](Images/Day27_Networking4.png)
|
||||
|
||||
However, we do not have anything inside this network so we need to add connections from the new network to each of our devices. (My networking knowledge needs more attention and I feel that you could just do this next step to the top router and then have connectivity to the rest of the network through this one cable?)
|
||||
しかし、このネットワーク内には何もないので、新しいネットワークから各機器への接続を追加する必要があります。(私のネットワークの知識はもっと注意が必要で、この次のステップを一番上のルーターに行い、この1本のケーブルを通して残りのネットワークに接続することができるような気がします?)
|
||||
|
||||
I have then logged on to each of our devices and I have run through the following commands for the interfaces applicable for where the cloud comes in.
|
||||
その後、各機器にログインし、クラウドが入る部分に該当するインターフェースに対して、以下のコマンドを実行しました。
|
||||
|
||||
```
|
||||
enable
|
||||
@ -38,7 +38,7 @@ exit
|
||||
sh ip int br
|
||||
```
|
||||
|
||||
The final step gives us the DHCP address from our home network. My device network list is as follows:
|
||||
最後のステップでは、ホームネットワークからDHCPアドレスを取得します。私のデバイスのネットワークリストは以下の通りです。
|
||||
|
||||
| Node | IP Address | Home Network IP |
|
||||
| ----------- | ----------- | ----------- |
|
||||
@ -48,81 +48,81 @@ The final step gives us the DHCP address from our home network. My device networ
|
||||
| Switch3 | 10.10.88.113| 192.168.169.125 |
|
||||
| Switch4 | 10.10.88.114| 192.168.169.197 |
|
||||
|
||||
### SSH to a network device
|
||||
### ネットワーク機器に SSH 接続する
|
||||
|
||||
With the above in place, we can now connect to our devices on our home network using our workstation. I am using Putty but also have access to other terminals such as git bash that give me the ability to SSH to our devices.
|
||||
以上で、ワークステーションを使用してホームネットワーク上のデバイスに接続できるようになりました。私は Putty を使っていますが、git bash のような他のターミナルも使えるので、デバイスに SSH 接続することができます。
|
||||
|
||||
Below you can see we have an SSH connection to our router device. (R1)
|
||||
以下は、ルーターに SSH 接続しているところです。(R1)
|
||||
|
||||
![](Images/Day27_Networking5.png)
|
||||
|
||||
### Using Python to gather information from our devices
|
||||
### Python を使ってデバイスから情報を収集する
|
||||
|
||||
The first example of how we can leverage Python is to gather information from all of our devices and in particular, I want to be able to connect to each one and run a simple command to provide me with interface configuration and settings. I have stored this script here [netmiko_con_multi.py](Networking/netmiko_con_multi.py)
|
||||
Python をどのように活用するかの最初の例は、すべてのデバイスから情報を収集することです。特に、それぞれのデバイスに接続して、インターフェースの構成と設定を提供する簡単なコマンドを実行できるようにしたいのです。このスクリプトは [netmiko_con_multi.py] (Networking/netmiko_con_multi.py) に保存されています。
|
||||
|
||||
Now when I run this I can see each port configuration over all of my devices.
|
||||
このスクリプトを実行すると、全てのデバイスの各ポートのコンフィギュレーションを見ることができます。
|
||||
|
||||
![](Images/Day27_Networking6.png)
|
||||
|
||||
This could be handy if you have a lot of different devices, create this one script so that you can centrally control and understand quickly all of the configurations in one place.
|
||||
このスクリプトを作成すれば、すべての設定を一元的に管理し、すばやく理解することができますので、さまざまなデバイスをたくさんお持ちの場合に便利です。
|
||||
|
||||
### Using Python to configure our devices
|
||||
### Python を使ってデバイスを設定する
|
||||
|
||||
The above is useful but what about using Python to configure our devices, in our scenario we have a trunked port between `SW1` and `SW2` again imagine if this was to be done across many of the same switches we want to automate that and not have to manually connect to each switch to make the configuration change.
|
||||
このシナリオでは、`SW1`と`SW2`の間にトランクされたポートがありますが、これが多くの同じスイッチ間で行われるとしたら、設定を変更するために各スイッチに手動で接続する必要がなく、自動化したいと思います。
|
||||
|
||||
We can use [netmiko_sendchange.py](Networking/netmiko_sendchange.py) to achieve this. This will connect over SSH and perform that change on our `SW1` which will also change to `SW2`.
|
||||
これを実現するために [netmiko_sendchange.py] (Networking/netmiko_sendchange.py) を使用することができます。これは SSH で接続し、`SW1` の変更を実行し、`SW2` にも変更を加えます。
|
||||
|
||||
![](Images/Day27_Networking7.png)
|
||||
|
||||
Now for those that look at the code, you will see the message appears and tells us `sending configuration to device` but there is no confirmation that this has happened to we could add additional code to our script to perform that check and validation on our switch or we could modify our script before to show us this. [netmiko_con_multi_vlan.py](Networking/netmiko_con_multi_vlan.py)
|
||||
今、コードを見ると、メッセージが表示され、`sending configuration to device` と表示されますが、これが起こったという確認はありません。このスクリプトに追加のコードを追加して、スイッチのチェックと検証を行うか、あるいは、このスクリプトを前に修正して、これを表示させます。[netmiko_con_multi_vlan.py](Networking/netmiko_con_multi_vlan.py)
|
||||
|
||||
![](Images/Day27_Networking8.png)
|
||||
|
||||
### backing up your device configurations
|
||||
### デバイス設定のバックアップ
|
||||
|
||||
Another use case would be to capture our network configurations and make sure we have those backed up, but again we don't want to be connecting to every device we have on our network so we can also automate this using [backup.py](Networking/backup.py). You will also need to populate the [backup.txt](Networking/backup.txt) with the IP addresses you want to backup.
|
||||
もう一つの使用例として、ネットワーク設定を取得し、バックアップしていることを確認します。backup.txt](Networking/backup.txt) にバックアップしたいIPアドレスを入力する必要があります。
|
||||
|
||||
Run your script and you should see something like the below.
|
||||
スクリプトを実行すると、以下のように表示されるはずです。
|
||||
|
||||
![](Images/Day27_Networking9.png)
|
||||
|
||||
That could be me just writing a simple print script in python so I should show you the backup files as well.
|
||||
それは私がpythonで簡単なprintスクリプトを書いているだけかもしれないので、バックアップファイルも見せるべきですね。
|
||||
|
||||
![](Images/Day27_Networking10.png)
|
||||
|
||||
### Paramiko
|
||||
### Paramiko
|
||||
|
||||
A widely used Python module for SSH. You can find out more at the official GitHub link [here](https://github.com/paramiko/paramiko)
|
||||
広く使われているSSH用のPythonモジュールです。GitHubの公式リンク[こちら](https://github.com/paramiko/paramiko)で詳細を見ることができます。
|
||||
|
||||
We can install this module using the `pip install paramiko` command.
|
||||
このモジュールは `pip install paramiko` コマンドでインストールすることができます。
|
||||
|
||||
![](Images/Day27_Networking1.png)
|
||||
|
||||
We can verify the installation by entering the Python shell and importing the paramiko module.
|
||||
Pythonのシェルに入り、paramikoモジュールをインポートすることで、インストールを確認することができます。
|
||||
|
||||
![](Images/Day27_Networking2.png)
|
||||
|
||||
### Netmiko
|
||||
### Netmiko
|
||||
|
||||
The netmiko module targets network devices specifically whereas paramiko is a broader tool for handling SSH connections overall.
|
||||
netmiko モジュールはネットワークデバイスに特化しており、paramiko は SSH 接続全般を扱うより広範なツールです。
|
||||
|
||||
Netmiko which we have used above alongside paramiko can be installed using `pip install netmiko`
|
||||
上記で paramiko と共に使用した Netmiko は `pip install netmiko` でインストールすることができます。
|
||||
|
||||
Netmiko supports many network vendors and devices, you can find a list of supported devices on the [GitHub Page](https://github.com/ktbyers/netmiko#supports)
|
||||
Netmikoは多くのネットワークベンダやデバイスをサポートしています。サポートされているデバイスの一覧は[GitHub Page](https://github.com/ktbyers/netmiko#supports)で見ることができます。
|
||||
|
||||
### Other modules
|
||||
### その他のモジュール
|
||||
|
||||
It is also worth mentioning a few other modules that we have not had the chance to look at but they give a lot more functionality when it comes to network automation.
|
||||
まだ見ていないモジュールもありますが、ネットワークの自動化に関して、より多くの機能を提供します。
|
||||
|
||||
`netaddr` is used for working with and manipulating IP addresses, again the installation is simple with `pip install netaddr`
|
||||
netaddr` は IP アドレスを操作するために使用され、インストールは `pip install netaddr` で簡単にできます。
|
||||
|
||||
you might find yourself wanting to store a lot of your switch configuration in an excel spreadsheet, the `xlrd` will allow your scripts to read the excel workbook and convert rows and columns into a matrix. `pip install xlrd` to get the module installed.
|
||||
xlrd` を使うと、スクリプトがエクセルのワークブックを読み込んで、行と列をマトリックスに変換することができます。モジュールをインストールするには `pip install xlrd` を実行してください。
|
||||
|
||||
Some more use cases where network automation can be used that I have not had the chance to look into can be found [here](https://github.com/ktbyers/pynet/tree/master/presentations/dfwcug/examples)
|
||||
ネットワークオートメーションの使用例として、まだ調べていないものがありますが、[ここ](https://github.com/ktbyers/pynet/tree/master/presentations/dfwcug/examples)で見ることができます。
|
||||
|
||||
I think this wraps up our Networking section of the #90DaysOfDevOps, Networking is one area that I have not touched for a while really and there is so much more to cover but I am hoping between my notes and the resources shared throughout it is helpful for some.
|
||||
ネットワークは、私がしばらく触れていない分野の一つで、まだまだカバーすべきことがたくさんありますが、私のメモと共有されたリソースが誰かの役に立つことを願っています。
|
||||
|
||||
## Resources
|
||||
## リソース
|
||||
|
||||
- [Free Course: Introduction to EVE-NG](https://www.youtube.com/watch?v=g6B0f_E0NMg)
|
||||
- [EVE-NG - Creating your first lab](https://www.youtube.com/watch?v=9dPWARirtK8)
|
||||
@ -131,8 +131,8 @@ I think this wraps up our Networking section of the #90DaysOfDevOps, Networking
|
||||
- [Practical Networking](http://www.practicalnetworking.net/)
|
||||
- [Python Network Automation](https://www.youtube.com/watch?v=xKPzLplPECU&list=WL&index=126)
|
||||
|
||||
Most of the examples I am using here as I am not a Network Engineer have come from this extensive book which is not free but I am using some of the scenarios to help understand Network Automation.
|
||||
私はネットワークエンジニアではないので、ここで使用している例のほとんどは、無料ではありませんが、ネットワークオートメーションの理解に役立つシナリオのいくつかを使用しているこの広範な書籍から来ました。
|
||||
|
||||
- [Hands-On Enterprise Automation with Python (Book)](https://www.packtpub.com/product/hands-on-enterprise-automation-with-python/9781788998512)
|
||||
|
||||
See you on [Day 28](day28.md) where will start looking into cloud computing and get a good grasp and foundational knowledge of the topic and what is available.
|
||||
[28日目](day28.md)では、クラウドコンピューティングについて調べ始め、この話題と何が利用可能かについて、よく理解し基礎知識を得るために、お会いしましょう。
|
||||
|
14
ja/README.md
14
ja/README.md
@ -48,13 +48,13 @@
|
||||
|
||||
### Understand Networking
|
||||
|
||||
- [✔️] 🌐 21 > [The Big Picture: DevOps and Networking](Days/day21.md)
|
||||
- [✔️] 🌐 22 > [The OSI Model - The 7 Layers](Days/day22.md)
|
||||
- [✔️] 🌐 23 > [Network Protocols](Days/day23.md)
|
||||
- [✔️] 🌐 24 > [Network Automation](Days/day24.md)
|
||||
- [✔️] 🌐 25 > [Python for Network Automation](Days/day25.md)
|
||||
- [✔️] 🌐 26 > [Building our Lab](Days/day26.md)
|
||||
- [✔️] 🌐 27 > [Getting Hands-On with Python & Network](Days/day27.md)
|
||||
- [✔️] 🌐 21 > [全体像: DevOpsとネットワーキング](Days/day21.md)
|
||||
- [✔️] 🌐 22 > [OSIモデル - 7つのレイヤー](Days/day22.md)
|
||||
- [✔️] 🌐 23 > [ネットワークプロトコル](Days/day23.md)
|
||||
- [✔️] 🌐 24 > [ネットワーク・オートメーションn](Days/day24.md)
|
||||
- [✔️] 🌐 25 > [Pythonによるネットワーク自動化](Days/day25.md)
|
||||
- [✔️] 🌐 26 > [ラボの構築](Days/day26.md)
|
||||
- [✔️] 🌐 27 > [ythonとネットワークのハンズオン](Days/day27.md)
|
||||
|
||||
### Stick to one Cloud Provider
|
||||
|
||||
|
64
ko/Days/day01.md
Normal file
64
ko/Days/day01.md
Normal file
@ -0,0 +1,64 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Introduction - Day 1'
|
||||
published: true
|
||||
description: 90DaysOfDevOps - Introduction
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048731
|
||||
date: '2022-04-17T10:12:40Z'
|
||||
---
|
||||
|
||||
## 개요 - Day 1
|
||||
|
||||
90일 중 1일차에는 데브옵스에 대한 기본적인 이해와 데브옵스적 사고방식을 돕는 도구에 대해서 학습합니다.
|
||||
|
||||
저는 몇 년 전부터 이 학습 여정을 시작했었습니다. 그 당시 가상화 플랫폼과 클라우드-기반 기술에 중점을 두어 학습하였고, 주로 코드형 인프라 (Infrastructure as Code)와 앱 구성관리를 테라폼과 셰프로 알아보고 있었습니다.
|
||||
|
||||
2021년 3월, Veeam의 Kasten사에서 클라우드 네이티브 전략에 대해 저의 노력을 쏟을 좋은 기회가 주어졌었습니다. 그것은 쿠버네티스와 데브옵스 그리고 관련 기술을 둘러싼 커뮤니티에 엄청난 관심을 끌게 될만한 것이었습니다. 저는 학습 여정을 시작하면서 쿠버네티스와 컨테이너화의 기초를 학습하는 것 외에도 아주 넓은 세계가 있다는 것을 알아차렸습니다. 그 시기는 제가 커뮤니티에서 발표하고, 데브옵스 문화, 툴 그리고 프로세스에 대해 학습해 나가기 시작할 때였습니다. 그래서 저는 학습하고 싶은 분야 중 일부 영역을 공개적으로 기록하기 시작했습니다.
|
||||
|
||||
[So you want to learn DevOps?](https://blog.kasten.io/devops-learning-curve)
|
||||
|
||||
## 여정을 시작하면서
|
||||
|
||||
위의 블로그를 읽고 저의 학습 여정의 수준이 매우 높을 것이라고 짐작하시는 분들을 위해 말씀드리면, 저는 그 분야들에 대해 전문가는 아닙니다만 유료이건 무료이건 어떤 형태로든 자료를 공유하고 싶었습니다. 우리는 모두 서로 다른 환경에 있을 것이니 각자에게 맞는 선택을 하시길 바랍니다.
|
||||
|
||||
앞으로 90일간 저는 기본적인 영역들에 대해 다루고 자료들을 문서화 하려고 합니다. 커뮤니티의 적극적인 참여도 바라고 있습니다. 많은 분의 학습 여정과 자료의 공유를 통해 공개적으로 함께 도와가며 서로 배우길 바랍니다.
|
||||
|
||||
프로젝트 리포지토리의 readme에 12주에 6일을 더한 분량의 섹션 별로 분할을 해두었습니다. 첫 6일간은 특정 영역에 뛰어들기 전에 데브옵스에 대한 전반적인 기본 지식들에 대해 학습할 것입니다. 반복해서 말씀드리면 저의 자료가 완벽하지 않습니다. 따라서 이 자료들이 유용하게 활용될 수 있도록 커뮤니티의 도움을 바랍니다.
|
||||
|
||||
지금 이 순간에 공유하고 싶은 자료가 하나 더 있습니다. 모두가 꼼꼼히 살펴야하고, 스스로에 대한, 자신의 관심과 현재 위치를 마인드맵으로 그려야할, 그것은
|
||||
|
||||
[DevOps Roadmap](https://roadmap.sh/devops)
|
||||
|
||||
이 주제에 대한 블로그 포스트, 초기 목록을 작성하는데 데브옵스 로드맵이 아주 유용하게 사용되었습니다. 본 리포지토리의 12가지 주제 이외에도 다른 영역에 대한 더 많은 정보를 얻을 수 있을 것입니다.
|
||||
|
||||
## 첫 단계 - 데브옵스란?
|
||||
|
||||
소개드리고 싶은 유튜브 비디오나 블로그 글이 너무 많습니다. 하지만 우리는 90일의 도전을 시작했고 매일 한시간씩 새로운 것을 배우거나 데브옵스에 관해 배우기로 했으므로, "DevOps란 무엇인가"라는 높은 수준의 정보를 먼저 얻는 것이 좋다고 생각합니다.
|
||||
|
||||
우선, 데브옵스는 도구가 아닙니다. 살 수 있는 것도 아니고, software SKU나 깃허브 레포지토리에서 다운로드 받을 수 있는 오픈 소스도 아닙니다. 또한 프로그래밍 언어도 아니고, 괴상한 흑마술도 아닙니다.
|
||||
|
||||
데브옵스란 소프트웨어 개발에서 좀 더 현명하게 일하는 방법을 말합니다. - 잠깐... 혹시 소프트웨어 개발자가 아니라면 이 학습 과정을 중단해야 할까요??? 아닙니다.. 데브옵스란 소프트웨어 개발과 운영의 통합을 의미하기 때문입니다. 위에서 언급했듯이 저는 일반적으로 운영에 속하는 VM(가상머신)과 관련된 쪽에 있었지만, 커뮤니티에는 다양한 배경을 가진 사람들이 있습니다. 그리고 개인, 개발자, 운영자 그리고 QA 엔지니어 모두는 DevOps를 더 잘 이해함으로써 모범사례에 관해 동등하게 배울 수 있습니다.
|
||||
|
||||
데브옵스는 이 목표를 달성하기 위한 일련의 관행입니다: 제품이 초기 아이디어 단계부터 최종 사용자, 내부 팀 또는 고객 등 모든 사용자에게 실제 운영 서비스로 전달되기 까지의 시간을 단축하는 것.
|
||||
|
||||
첫 주에 다룰 또 다른 분야는 **애자일 방법론** 에 관한 것입니다. 애플리케이션을 지속적으로 전달(Continuous Delivery)하기 위해 데브옵스와 애자일은 주로 함께 다루어집니다.
|
||||
|
||||
개략적으로 말해 데브옵스적 사고방식이나 문화는 길고 몇년이 걸릴 수 있는 소프트웨어 배포 프로세스를 더 작고, 자주 배포하는 방식으로 시간을 단축시키는 것입니다. 추가로 이해해야할 또 다른 핵심 포인트는 위에 언급한 개발, 운영, QA 팀간의 사일로를 무너트리는 것은 데브옵스 엔지니어의 책임입니다.
|
||||
|
||||
데브옵스의 관점에서 보면 **개발, 테스트, 배포**는 모두 데브옵스 팀과 함께 해야하기 때문입니다.
|
||||
|
||||
최종적으로 이런 것을 효과적이고 효율적으로 하기 위해서는 **자동화**를 최대한 활용해야 합니다.
|
||||
|
||||
## 자료
|
||||
|
||||
이곳을 학습 도구로 활용하기 위해 이 readme 파일에 추가적으로 자료를 덪붙이는 것에 대해 항상 열려있습니다.
|
||||
|
||||
그리고 아래 동영상들을 꼭 보시기 바랍니다. 또한 위에 설명드린 내용에서 많은 인사이트를 얻었으면 합니다.
|
||||
|
||||
- [DevOps in 5 Minutes](https://www.youtube.com/watch?v=Xrgk023l4lI)
|
||||
- [What is DevOps? Easy Way](https://www.youtube.com/watch?v=_Gpe1Zn-1fE&t=43s)
|
||||
- [DevOps roadmap 2022 | Success Roadmap 2022](https://www.youtube.com/watch?v=7l_n97Mt0ko)
|
||||
|
||||
여기까지 읽었다면 나에게 필요한 내용인지 아닌지 알 수 있을 것입니다. [Day 2](day02.md)
|
166
ko/README.md
Normal file
166
ko/README.md
Normal file
@ -0,0 +1,166 @@
|
||||
# 90DaysOfDevOps
|
||||
|
||||
<p align="center">
|
||||
<img src="https://github.com/MichaelCade/90DaysOfDevOps/blob/main/logo.png?raw=true" alt="90DaysOfDevOps Logo" width="50%" height="50%" />
|
||||
</p>
|
||||
|
||||
이 리포지토리는 "DevOps"의 기본적인 지식을 학습해 나가기 위한 나의 여정을 문서화 하기 위해 사용합니다. 2022년 1월 1일에 여정을 시작할 예정이며 90일이 소요됩니다. 딱 마침 1월 1일부터 3월 31일까지 입니다.
|
||||
|
||||
최근 들어 문서를 만드는 이유는 다른 사람들이 나의 문서를 통해 무엇인가를 얻을 수 있고, 또한 자료들이 많이 강화될 수 있다고 믿기 때문입니다.
|
||||
|
||||
목표는 하루 한 시간씩 90일 동안 "DevOps"의 13가지 영역에 대한 기본적인 지식을 학습하는 것입니다.
|
||||
|
||||
"DevOps"에 대한 **모든 것들을 다루지는 않습니다** 하지만, 전반적인 이해화 학습을 돕는 영역에 대해서 다루게 됩니다.
|
||||
|
||||
[![ko-fi](https://ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/N4N33YRCS)
|
||||
|
||||
트위터를 통해서 저와 가장 빠르게 연락을 닿을 수 있습니다. [@MichaelCade1](https://twitter.com/MichaelCade1)
|
||||
|
||||
## 과정
|
||||
|
||||
- [✔️] ♾️ 1 > [개요](Days/day01.md)
|
||||
|
||||
### What is and why do we use DevOps
|
||||
|
||||
- [✔️] ♾️ 2 > [Responsibilities of a DevOps Engineer](Days/day02.md)
|
||||
- [✔️] ♾️ 3 > [DevOps Lifecycle - Application Focused](Days/day03.md)
|
||||
- [✔️] ♾️ 4 > [DevOps & Agile](Days/day04.md)
|
||||
- [✔️] ♾️ 5 > [Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor >](Days/day05.md)
|
||||
- [✔️] ♾️ 6 > [DevOps - The real stories](Days/day06.md)
|
||||
|
||||
### Learning a Programming Language
|
||||
|
||||
- [✔️] ⌨️ 7 > [The Big Picture: DevOps & Learning a Programming Language](Days/day07.md)
|
||||
- [✔️] ⌨️ 8 > [Setting up your DevOps environment for Go & Hello World](Days/day08.md)
|
||||
- [✔️] ⌨️ 9 > [Let's explain the Hello World code](Days/day09.md)
|
||||
- [✔️] ⌨️ 10 > [The Go Workspace & Compiling & running code](Days/day10.md)
|
||||
- [✔️] ⌨️ 11 > [Variables, Constants & Data Types](Days/day11.md)
|
||||
- [✔️] ⌨️ 12 > [Getting user input with Pointers and a finished program](Days/day12.md)
|
||||
- [✔️] ⌨️ 13 > [Tweet your progress with our new App](Days/day13.md)
|
||||
|
||||
### Knowing Linux Basics
|
||||
|
||||
- [✔️] 🐧 14 > [The Big Picture: DevOps and Linux](Days/day14.md)
|
||||
- [✔️] 🐧 15 > [Linux Commands for DevOps (Actually everyone)](Days/day15.md)
|
||||
- [✔️] 🐧 16 > [Managing your Linux System, Filesystem & Storage](Days/day16.md)
|
||||
- [✔️] 🐧 17 > [Text Editors - nano vs vim](Days/day17.md)
|
||||
- [✔️] 🐧 18 > [SSH & Web Server(LAMP)](Days/day18.md)
|
||||
- [✔️] 🐧 19 > [Automate tasks with bash scripts](Days/day19.md)
|
||||
- [✔️] 🐧 20 > [Dev workstation setup - All the pretty things](Days/day20.md)
|
||||
|
||||
### Understand Networking
|
||||
|
||||
- [✔️] 🌐 21 > [The Big Picture: DevOps and Networking](Days/day21.md)
|
||||
- [✔️] 🌐 22 > [The OSI Model - The 7 Layers](Days/day22.md)
|
||||
- [✔️] 🌐 23 > [Network Protocols](Days/day23.md)
|
||||
- [✔️] 🌐 24 > [Network Automation](Days/day24.md)
|
||||
- [✔️] 🌐 25 > [Python for Network Automation](Days/day25.md)
|
||||
- [✔️] 🌐 26 > [Building our Lab](Days/day26.md)
|
||||
- [✔️] 🌐 27 > [Getting Hands-On with Python & Network](Days/day27.md)
|
||||
|
||||
### Stick to one Cloud Provider
|
||||
|
||||
- [✔️] ☁️ 28 > [The Big Picture: DevOps & The Cloud](Days/day28.md)
|
||||
- [✔️] ☁️ 29 > [Microsoft Azure Fundamentals](Days/day29.md)
|
||||
- [✔️] ☁️ 30 > [Microsoft Azure Security Models](Days/day30.md)
|
||||
- [✔️] ☁️ 31 > [Microsoft Azure Compute Models](Days/day31.md)
|
||||
- [✔️] ☁️ 32 > [Microsoft Azure Storage & Database Models](Days/day32.md)
|
||||
- [✔️] ☁️ 33 > [Microsoft Azure Networking Models + Azure Management](Days/day33.md)
|
||||
- [✔️] ☁️ 34 > [Microsoft Azure Hands-On Scenarios](Days/day34.md)
|
||||
|
||||
### Use Git Effectively
|
||||
|
||||
- [✔️] 📚 35 > [The Big Picture: Git - Version Control](Days/day35.md)
|
||||
- [✔️] 📚 36 > [Installing & Configuring Git](Days/day36.md)
|
||||
- [✔️] 📚 37 > [Gitting to know Git](Days/day37.md)
|
||||
- [✔️] 📚 38 > [Staging & Changing](Days/day38.md)
|
||||
- [✔️] 📚 39 > [Viewing, unstaging, discarding & restoring](Days/day39.md)
|
||||
- [✔️] 📚 40 > [Social Network for code](Days/day40.md)
|
||||
- [✔️] 📚 41 > [The Open Source Workflow](Days/day41.md)
|
||||
|
||||
### Containers
|
||||
|
||||
- [✔️] 🏗️ 42 > [The Big Picture: Containers](Days/day42.md)
|
||||
- [✔️] 🏗️ 43 > [What is Docker & Getting installed](Days/day43.md)
|
||||
- [✔️] 🏗️ 44 > [Docker Images & Hands-On with Docker Desktop](Days/day44.md)
|
||||
- [✔️] 🏗️ 45 > [The anatomy of a Docker Image](Days/day45.md)
|
||||
- [✔️] 🏗️ 46 > [Docker Compose](Days/day46.md)
|
||||
- [✔️] 🏗️ 47 > [Docker Networking & Security](Days/day47.md)
|
||||
- [✔️] 🏗️ 48 > [Alternatives to Docker](Days/day48.md)
|
||||
|
||||
### Kubernetes
|
||||
|
||||
- [✔️] ☸ 49 > [The Big Picture: Kubernetes](Days/day49.md)
|
||||
- [✔️] ☸ 50 > [Choosing your Kubernetes platform](Days/day50.md)
|
||||
- [✔️] ☸ 51 > [Deploying your first Kubernetes Cluster](Days/day51.md)
|
||||
- [✔️] ☸ 52 > [Setting up a multinode Kubernetes Cluster](Days/day52.md)
|
||||
- [✔️] ☸ 53 > [Rancher Overview - Hands On](Days/day53.md)
|
||||
- [✔️] ☸ 54 > [Kubernetes Application Deployment](Days/day54.md)
|
||||
- [✔️] ☸ 55 > [State and Ingress in Kubernetes](Days/day55.md)
|
||||
|
||||
### Learn Infrastructure as Code
|
||||
|
||||
- [✔️] 🤖 56 > [The Big Picture: IaC](Days/day56.md)
|
||||
- [✔️] 🤖 57 > [An intro to Terraform](Days/day57.md)
|
||||
- [✔️] 🤖 58 > [HashiCorp Configuration Language (HCL)](Days/day58.md)
|
||||
- [✔️] 🤖 59 > [Create a VM with Terraform & Variables](Days/day59.md)
|
||||
- [✔️] 🤖 60 > [Docker Containers, Provisioners & Modules](Days/day60.md)
|
||||
- [✔️] 🤖 61 > [Kubernetes & Multiple Environments](Days/day61.md)
|
||||
- [✔️] 🤖 62 > [Testing, Tools & Alternatives](Days/day62.md)
|
||||
|
||||
### Automate Configuration Management
|
||||
|
||||
- [✔️] 📜 63 > [The Big Picture: Configuration Management](Days/day63.md)
|
||||
- [✔️] 📜 64 > [Ansible: Getting Started](Days/day64.md)
|
||||
- [✔️] 📜 65 > [Ansible Playbooks](Days/day65.md)
|
||||
- [✔️] 📜 66 > [Ansible Playbooks Continued...](Days/day66.md)
|
||||
- [✔️] 📜 67 > [Using Roles & Deploying a Loadbalancer](Days/day67.md)
|
||||
- [✔️] 📜 68 > [Tags, Variables, Inventory & Database Server config](Days/day68.md)
|
||||
- [✔️] 📜 69 > [All other things Ansible - Automation Controller, AWX, Vault](Days/day69.md)
|
||||
|
||||
### Create CI/CD Pipelines
|
||||
|
||||
- [✔️] 🔄 70 > [The Big Picture: CI/CD Pipelines](Days/day70.md)
|
||||
- [✔️] 🔄 71 > [What is Jenkins?](Days/day71.md)
|
||||
- [✔️] 🔄 72 > [Getting hands on with Jenkins](Days/day72.md)
|
||||
- [✔️] 🔄 73 > [Building a Jenkins pipeline](Days/day73.md)
|
||||
- [✔️] 🔄 74 > [Hello World - Jenkinsfile App Pipeline](Days/day74.md)
|
||||
- [✔️] 🔄 75 > [GitHub Actions Overview](Days/day75.md)
|
||||
- [✔️] 🔄 76 > [ArgoCD Overview](Days/day76.md)
|
||||
|
||||
### Monitoring, Log Management, and Data Visualisation
|
||||
|
||||
- [✔️] 📈 77 > [The Big Picture: Monitoring](Days/day77.md)
|
||||
- [✔️] 📈 78 > [Hands-On Monitoring Tools](Days/day78.md)
|
||||
- [✔️] 📈 79 > [The Big Picture: Log Management](Days/day79.md)
|
||||
- [✔️] 📈 80 > [ELK Stack](Days/day80.md)
|
||||
- [✔️] 📈 81 > [Fluentd & FluentBit](Days/day81.md)
|
||||
- [✔️] 📈 82 > [EFK Stack](Days/day82.md)
|
||||
- [✔️] 📈 83 > [Data Visualisation - Grafana](Days/day83.md)
|
||||
|
||||
### Store & Protect Your Data
|
||||
|
||||
- [✔️] 🗃️ 84 > [The Big Picture: Data Management](Days/day84.md)
|
||||
- [✔️] 🗃️ 85 > [Data Services](Days/day85.md)
|
||||
- [✔️] 🗃️ 86 > [Backup all the platforms](Days/day86.md)
|
||||
- [✔️] 🗃️ 87 > [Hands-On Backup & Recovery](Days/day87.md)
|
||||
- [✔️] 🗃️ 88 > [Application Focused Backups](Days/day88.md)
|
||||
- [✔️] 🗃️ 89 > [Disaster Recovery](Days/day89.md)
|
||||
- [✔️] 🗃️ 90 > [Data & Application Mobility](Days/day90.md)
|
||||
|
||||
## License
|
||||
|
||||
Shield: [![CC BY-NC-SA 4.0][cc-by-nc-sa-shield]][cc-by-nc-sa]
|
||||
|
||||
This work is licensed under a
|
||||
[Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License][cc-by-nc-sa].
|
||||
|
||||
[![CC BY-NC-SA 4.0][cc-by-nc-sa-image]][cc-by-nc-sa]
|
||||
|
||||
## Star History
|
||||
|
||||
[![Star History Chart](https://api.star-history.com/svg?repos=MichaelCade/90DaysOfDevOps&type=Timeline)](https://star-history.com/#MichaelCade/90DaysOfDevOps&Timeline)
|
||||
|
||||
[cc-by-nc-sa]: http://creativecommons.org/licenses/by-nc-sa/4.0/
|
||||
[cc-by-nc-sa-image]: https://licensebuttons.net/l/by-nc-sa/4.0/88x31.png
|
||||
[cc-by-nc-sa-shield]: https://img.shields.io/badge/License-CC%20BY--NC--SA%204.0-lightgrey.svg
|
57
pl/day02.md
57
pl/day02.md
@ -1,68 +1,69 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Responsibilities of a DevOps Engineer - Day 2'
|
||||
title: '#90DaysOfDevOps - Zadania DevOps Engineera - Dzień 2'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Responsibilities of a DevOps Engineer
|
||||
description: 90DaysOfDevOps - Zadania DevOps Engineera - Dzień 2
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048699
|
||||
date: '2022-04-17T21:15:34Z'
|
||||
---
|
||||
## Responsibilities of a DevOps Engineer
|
||||
## Zadania DevOps Engineera - Dzień 2
|
||||
|
||||
Hopefully, you are coming into this off the back of going through the resources and posting on [Day1 of #90DaysOfDevOps](day01.md)
|
||||
Mam nadzieję, że wracasz tutaj po przerobieniu tekstu z poprzedniego dnia [Dzień 1 #90DaysOfDevOps](day02.md)
|
||||
|
||||
It was briefly touched on in the first post but now we must get deeper into this concept and understand that there are two main parts when creating an application. We have the **Development** part where software developers program the application and test it. Then we have the **Operations** part where the application is deployed and maintained on a server.
|
||||
W pierwszym poście poruszyliśmy podstawowe zagadnienia, lecz teraz musimy przyjrzeć się dokładniej poszczególnym konceptom i zrozumieć, że na wytwarzanie oprogramowania składają się dwa obszary. **Development (rozwój)**, gdzie programiści(developerzy) tworzą i testują aplikację. Oraz **Operations (utrzymanie)**, gdzie aplikacja jest wdrażana i utrzymywana na serwerze.
|
||||
|
||||
## DevOps is the link between the two
|
||||
## DevOps to pomost pomiędzy nimi
|
||||
|
||||
To get to grips with DevOps or the tasks which a DevOps engineer would be carrying out we need to understand the tools or the process and overview of those and how they come together.
|
||||
Aby zrozumieć DevOps i zadania, za które Inżynier DevOps jest odpowiedzialny, musimy zrozumieć narzędzia lub procesy związane z tym, jak te dwa światy się łączą.
|
||||
|
||||
Everything starts with the application! You will see so much throughout that it is all about the application when it comes to DevOps.
|
||||
Wszystko zaczyna się od aplikacji! W trakcie nauki zrozumiesz, że tak naprawdę wszystko co dotyczy DevOpsu tyczy się aplikacji.
|
||||
|
||||
Developers will create an application, this can be done with many different technology stacks and let's leave that to the imagination for now as we get into this later. This can also involve many different programming languages, build tools, code repositories etc.
|
||||
Developerzy tworzą oprogramowanie, mogą to robić z użyciem wielu różnych stacków technologicznych, w późniejszych rozdziałach poświęcimy temu procesowi więcej uwagi. Wytwarzanie oprogramowania może wiązać się z użyciem wielu różnych języków programowania, narzędzi do budowania aplikacji, repozytoriów kodu itd.
|
||||
|
||||
As a DevOps engineer you won't be programming the application but having a good understanding of the concepts of how a developer works and the systems, tools and processes they are using is key to success.
|
||||
Jako DevOps engineer nie będziesz programować samej aplikacji, ale dobre zrozumienie konceptów, z którymi pracują developerzy, oraz zrozumienie systemów, narzędzi i procesów z jakich korzystają jest kluczem do osiągnięcia sukcesu.
|
||||
|
||||
At a very high level, you are going to need to know how the application is configured to talk to all of its required services or data services and then also sprinkle a requirement of how this can or should be tested.
|
||||
Wysokopoziomowo, będziesz potrzebować wiedzieć o tym jak aplikacja jest skonfigurowana, by móc rozmawiać z wszystkimi wymaganymi serwisami, oraz znać wymogi tego, jak taką komunikację testować.
|
||||
|
||||
The application will need to be deployed somewhere, lets's keep it generally simple here and make this a server, doesn't matter where but a server. This is then expected to be accessed by the customer or end user depending on the application that has been created.
|
||||
Aplikacja musi być gdzieś wdrożona, dla uproszczenia przyjmijmy, że jest to serwer, nieważne jaki, po prostu serwer. Zakładamy również, że ten serwer powinien być dostępny dla klienta lub użytkowanika końcowego aplikacji.
|
||||
|
||||
This server needs to run somewhere, on-premises, in a public cloud, serverless (Ok I have gone too far, we won't be covering serverless but its an option and more and more enterprises are heading this way) Someone needs to create and configure these servers and get them ready for the application to run. Now, this element might land to you as a DevOps engineer to deploy and configure these servers.
|
||||
Ten serwer musi istnieć w jakiejś określonej konfiguracji – on premises, w publicznym cloudzie, serverless (Ok, wybiegamy tutaj trochę za daleko, ten projekt nie pokrywa serverless, jednak jest to jedna z możliwości i coraz więcej firm wybiera ten model). Ktoś musi te serwery stworzyć i skonfigurować, aby przygotować je do hostowania aplikacji. Ten obszar, skonfigurowania i wdrożenia tych serwerów, może leżeć w zakresie twoich obowiązków jako DevOps Engineera.
|
||||
|
||||
These servers run an operating system and generally speaking this is going to be Linux but we have a whole section or week where we cover some of the foundational knowledge you should gain here.
|
||||
Na tych serwerach uruchomiony jest jakiś system operacyjny, zazwyczaj jest to Linux, poświęcimy całą sekcję/tydzień na pokrycie podstawowej wiedzy, jaką powinienieś/aś zdobyć w tym obszarze.
|
||||
|
||||
It is also likely that we need to communicate with other services in our network or environment, so we also need to have that level of knowledge around networking and configuring that, this might to some degree also land at the feet of the DevOps engineer. Again we will cover this in more detail in a dedicated section talking about all things DNS, DHCP, Load Balancing etc.
|
||||
Prawdopodobne jest również, że dany serwer będzie potrzebował komunikować się z innymi serwisami w naszej sieci lub środowisku, więc będziemy również potrzebować odpowiedniej wiedzy z zakresu sieci i ich konfiguracji, jako, że ten obszar również będzie znajdować się w kometencjach DevOps Engineera. Bardziej szczegółowe informacje znajdziesz w odpowiednich sekcjach, gdzie będizemy mówić o wszystkim związanym z DNSami, DHCP, Load Balancigiem itd.
|
||||
|
||||
## Jack of all trades, Master of none
|
||||
|
||||
I will say at this point though, you don't need to be a Network or Infrastructure specialist you need a foundational knowledge of how to get things up and running and talking to each other, much the same as maybe having a foundational knowledge of a programming language but you don't need to be a developer. However, you might be coming into this as a specialist in an area and that is a great footing to adapt to other areas.
|
||||
Na tym etapie należałoby zaznaczyć, że nie potrzebujesz eksperckiej wiedzy z zakresu sieci, czy infrastruktury. Potrzebujesz jedynie podstawowej wiedzy na temat tego, jak skonfigurować wszystko co jest potrzebne, żeby poszczególne zasoby mogły działać i rozmawiać ze sobą nawzajem. Podobnie jest z wiedzą w zakresie języków programowania. Nie musisz być developerem. Jednak możesz przejść do DevOpsu jako specjalista w danym obszarze i możę to być świetna podstawa do zaadaptowania do innych obszarów.
|
||||
|
||||
You will also most likely not take over the management of these servers or the application daily.
|
||||
Prawdopodobnie również nie przejmiesz odpowiedzialności w kwestii codziennego zarządzania serwerami lub aplikacjami.
|
||||
|
||||
We have been talking about servers but the likelihood is that your application will be developed to run as containers, Which still runs on a server for the most part but you will also need an understanding of not only virtualisation, Cloud Infrastructure as a Service (IaaS) but also containerisation as well, The focus in these 90 days will be more catered towards containers.
|
||||
Mówiliśmy o sewerach, ale prawdopodobnie twoja aplikacja będzie tworzona z myślą o działaniu w kontenerach, które również zazwyczaj działają na serwerze, ale w tym przypadku również musisz rozumieć koncepty takie jak wirtualizacja, chmurowe Infrastructure as a Service (IaaS), ale również konteneryzacji. Podczas tych 90 dni skupimy się przede wszystkim na kontenerach.
|
||||
|
||||
## High-Level Overview
|
||||
## Podsumowanie wysokopoziomowe
|
||||
|
||||
On one side we have our developers creating new features and functionality (as well as bug fixes) for the application.
|
||||
Z jednej strony mamy developerów, tworzących nowe ficzery i funkcjonalności (jak i naprawiających bugi) dla danej aplikacji.
|
||||
|
||||
On the other side, we have some sort of environment, infrastructure or servers which are configured and managed to run this application and communicate with all its required services.
|
||||
Z drugiej strony, mamy jakiegoś rodzaju środowisko, infrastrukturę i serwery, które należy skonfigurować i którymi trzeba zarządzać, aby były w stanie obsługiwać tę aplikację i komunikować się ze wszystkimi wymaganymi usługami i serwisami
|
||||
|
||||
The big question is how do we get those features and bug fixes into our products and make them available to those end users?
|
||||
W takiej sytuacji należy zadać sobie pytanie, w jaki sposób chcemy zaimplementować te funkcjonalności i poprawki do naszego produktu i sprawić, by były dostępne dla użytkowników końcowych?
|
||||
|
||||
How do we release the new application version? This is one of the main tasks for a DevOps engineer, and the important thing here is not to just figure out how to do this once but we need to do this continuously and in an automated, efficient way which also needs to include testing!
|
||||
W jaki sposób chcemy wypuścić nową wersję aplikacji? To jedno z głównych zadań inżyniera DevOps, co ważne, nie polega to jedynie na znalezieniu jednorazowego rozwiązania, ale musimy robić to w sposób ciągły zautomatyzowany i efektywny, oraz włączyć do całego procesu testowanie tego oprogramowania.
|
||||
|
||||
This is where we are going to end this day of learning, hopefully, this was useful. Over the next few days, we are going to dive a little deeper into some more areas of DevOps and then we will get into the sections that dive deeper into the tooling and processes and the benefits of these.
|
||||
Na tym etapie zakończymy dzisiejszy dzień nauki, mając nadzieję, że ta wiedza była przydatna. Następne kilka dni poświęcimy na głębsze spojrzenie na poszczególne obszary DevOps oraz spojrzymy dokładniej na narzędzia, procesy i korzyści z takich rozwiązań.
|
||||
|
||||
## Resources
|
||||
## Dodatkowe źródła
|
||||
|
||||
I am always open to adding additional resources to these readme files as it is here as a learning tool.
|
||||
Zawsze jestem otwarty na dodawanie dodatkowych źródeł do tych plików readme, jako, że służą one pogłębieniu wiedzy.
|
||||
|
||||
Moja rada to obejrzenie wszystkich poniższych filmów i mam nadzieję, że również wyciągnęliście jakieś użyteczne informacje z powyższego tekstu
|
||||
|
||||
My advice is to watch all of the below and hopefully you also picked something up from the text and explanations above.
|
||||
- [What is DevOps? - TechWorld with Nana](https://www.youtube.com/watch?v=0yWAtQ6wYNM)
|
||||
- [What is DevOps? - GitHub YouTube](https://www.youtube.com/watch?v=kBV8gPVZNEE)
|
||||
- [What is DevOps? - IBM YouTube](https://www.youtube.com/watch?v=UbtB4sMaaNM)
|
||||
- [What is DevOps? - AWS ](https://aws.amazon.com/devops/what-is-devops/)
|
||||
- [What is DevOps? - Microsoft](https://docs.microsoft.com/en-us/devops/what-is-devops)
|
||||
|
||||
If you made it this far then you will know if this is where you want to be or not. See you on [Day 3](day03.md).
|
||||
Jeżeli dotarłeś/aś do tego momentu, już wiesz, czy chcesz iść dalej tą drogą. Do zoabaczenia w [Dniu 3](day03.md).
|
||||
|
64
pt-br/Days/day01.md
Normal file
64
pt-br/Days/day01.md
Normal file
@ -0,0 +1,64 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Introdução - Dia 1'
|
||||
published: true
|
||||
description: 90DaysOfDevOps - Introdução
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048731
|
||||
date: '2022-13-13T10:12:40Z'
|
||||
---
|
||||
|
||||
## Introdução - Dia 1
|
||||
|
||||
Dia 1 dos nossos 90 dias de aventura para aprender um bom entendimento básico de DevOps e ferramentas que ajudam com uma mentalidade de DevOps.
|
||||
|
||||
Essa jornada de aprendizado começou para mim há alguns anos, mas meu foco era em plataformas de virtualização e tecnologias baseadas em nuvem, eu estava olhando principalmente para infraestrutura como código e gerenciamento de configuração de aplicações com Terraform e Chef.
|
||||
|
||||
Avançando para março de 2021, tive uma oportunidade incrível de concentrar meus esforços na estratégia _Cloud Native_ na Kasten da Veeam. O que seria um foco maciço no Kubernetes e DevOps além de todo ecossistema em torno dessas tecnologias. Comecei minha jornada de aprendizado e rapidamente percebi que havia um mundo muito amplo além de apenas aprender os fundamentos do Kubernetes e da Containerização, e foi então que comecei a falar com a comunidade e aprender cada vez mais sobre a cultura, ferramentas e processos de DevOps. Então eu comecei a documentar publicamente algumas das áreas que eu queria aprender.
|
||||
|
||||
[Então você quer aprender DevOps?](https://blog.kasten.io/devops-learning-curve)
|
||||
|
||||
## Deixe a jornada começar
|
||||
|
||||
Se você ler o blog acima, verá que este é um conteúdo de alto nível para minha jornada de aprendizado e direi que neste momento não sou nem de longe um especialista em nenhuma dessas seções, mas o que eu queria fazer era compartilhar alguns recursos tanto GRÁTIS quanto pagos, mas uma opção para ambos, pois todos temos circunstâncias diferentes.
|
||||
|
||||
Nos próximos 90 dias, quero documentar esses recursos e cobrir essas áreas fundamentais. Eu adoraria que a comunidade também se envolvesse. Compartilhe sua jornada e recursos para que possamos aprender em público e ajudar uns aos outros.
|
||||
|
||||
Você verá no _README_ de abertura no repositório do projeto, que dividi as coisas em seções e são 12 semanas mais 6 dias. Nos primeiros 6 dias, exploraremos os fundamentos do DevOps em geral antes de mergulhar em algumas das áreas específicas. De forma alguma esta lista é exaustiva e, novamente, eu adoraria que a comunidade ajudasse a tornar este um recurso útil.
|
||||
|
||||
Outro recurso que compartilharei neste momento e que acho que todos deveriam dar uma boa olhada, talvez criar seu próprio mapa mental com assuntos de seu interesse é o seguinte:
|
||||
|
||||
[Roteiro do DevOps](https://roadmap.sh/devops)
|
||||
|
||||
Achei isso um ótimo recurso quando estava criando minha lista inicial e as postagens no blog sobre esse tópico. Você também pode ver outras áreas em detalhes além dos 12 tópicos que listei aqui neste repositório.
|
||||
|
||||
## Primeiros Passos - O que é DevOps?
|
||||
|
||||
Há tantos artigos de blog e vídeos do YouTube para listar aqui, mas quando começamos o desafio de 90 dias e nos concentramos em passar cerca de uma hora por dia aprendendo algo novo ou sobre DevOps, achei que seria bom obter alguns de altos níve sobre "o que é DevOps" para começar.
|
||||
|
||||
Em primeiro lugar, DevOps não é uma ferramenta. Você não pode comprá-lo, não é um SKU de software ou um repositório GitHub de código aberto que você pode baixar. Também não é uma linguagem de programação, também não é uma arte de magia negra.
|
||||
|
||||
DevOps é uma maneira de fazer coisas mais inteligentes no desenvolvimento de software. - Espera... Mas se você não é um desenvolvedor de software deveria se afastar agora e não mergulhar nesse projeto??? Não. De jeito nenhum. Fique... Porque o DevOps reúne uma combinação de desenvolvimento de software e operações. Mencionei anteriormente que eu estava mais no lado da VM e isso geralmente se enquadraria no lado de operações da casa, mas dentro da comunidade, existem pessoas com diferentes origens onde o DevOps é 100% benéfico para o indivíduo, para desenvolvedores e para operações. Engenheiros de QA podem aprender igualmente essas práticas recomendadas tendo uma melhor compreensão do DevOps.
|
||||
|
||||
DevOps é um conjunto de práticas que ajudam a atingir o objetivo desse movimento: reduzir o tempo entre a fase de ideação de um produto e seu lançamento em produção para o usuário final ou qualquer que seja uma equipe interna ou ainda, o cliente.
|
||||
|
||||
Outra área em que vamos mergulhar nesta primeira semana é em torno da **Metodologia Ágil**. DevOps e Agile são amplamente adotados juntos para obter entrega contínua de suas **Aplicações**.
|
||||
|
||||
A conclusão de alto nível é que uma mentalidade ou cultura DevOps serve para reduzir o longo e prolongado processo de lançamento de software de potencialmente anos, para poder lançar versões menores com mais frequência. O outro ponto fundamental a ser entendido aqui é a responsabilidade de um engenheiro de DevOps em dividir os silos entre as equipes que mencionei anteriormente: Desenvolvedores, Operações e QA.
|
||||
|
||||
Do ponto de vista do DevOps, **Desenvolvimento, Teste e Implantação** chegam à equipe de DevOps.
|
||||
|
||||
O ponto final que farei é que para tornar isso o mais eficaz e eficiente possível, devemos aproveitar a **Automação**.
|
||||
|
||||
## Recursos
|
||||
|
||||
Estou sempre aberto a adicionar recursos adicionais a esses arquivos README, pois estão aqui como uma ferramenta de aprendizado.
|
||||
|
||||
Meu conselho é assistir a todos os itens abaixo e espero que você também tenha captado algo do texto e das explicações acima.
|
||||
|
||||
- [DevOps em 5 minutos](https://www.youtube.com/watch?v=Xrgk023l4lI)
|
||||
- [O que é DevOps? Maneira Fácil](https://www.youtube.com/watch?v=_Gpe1Zn-1fE&t=43s)
|
||||
- [Roteiro de DevOps 2022 | Roteiro de sucesso 2022](https://www.youtube.com/watch?v=7l_n97Mt0ko)
|
||||
|
||||
Se você chegou até aqui, saberá se é aqui que você quer estar ou não. Vejo você no [Dia 2](day02.md).
|
71
pt-br/Days/day02.md
Normal file
71
pt-br/Days/day02.md
Normal file
@ -0,0 +1,71 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Responsabilidades de um engenheiro de DevOps - Dia 2'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Responsabilidades de um engenheiro de DevOps
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048699
|
||||
date: '2022-10-13T11:17:00Z'
|
||||
---
|
||||
|
||||
## Responsabilidades de um engenheiro de DevOps
|
||||
|
||||
Espero que você esteja chegando aqui depois de analisar os recursos postados no [Dia1 de #90DiasDeDevOps](dia01.md)
|
||||
|
||||
Isso foi brevemente abordado no primeiro post, mas agora devemos nos aprofundar nesse conceito e entender que existem duas partes principais ao criar uma aplicação. Temos a parte de **Desenvolvimento** onde os desenvolvedores de software programam a aplicação e o testam. Em seguida, temos a parte de **Operações** em que a aplicação é implantada e mantida em um servidor.
|
||||
|
||||
## DevOps é o elo entre os dois
|
||||
|
||||
Para entender DevOps ou as tarefas que um engenheiro de DevOps estaria realizando, precisamos entender as ferramentas ou o processo e a visão geral delas e como elas se unem.
|
||||
|
||||
Tudo começa com a aplicação! Você verá que é tudo sobre a aplicação quando se trata de DevOps.
|
||||
|
||||
Os desenvolvedores criarão uma aplicação, isso pode ser feito com muitas pilhas de tecnologia diferentes e vamos deixar isso para a imaginação por enquanto, pois entraremos nisso mais tarde. Isso também pode envolver muitas linguagens de programação diferentes, ferramentas de construção, repositórios de código etc.
|
||||
|
||||
Como engenheiro de DevOps, você não estará programando a aplicação, mas ter uma boa compreensão dos conceitos de como um desenvolvedor trabalha e dos sistemas, ferramentas e processos que estão usando é a chave para o sucesso.
|
||||
|
||||
Em um nível muito alto, você precisará saber como o aplicativo está configurado para se comunicar com todos os seus serviços ou serviços de dados necessários e, em seguida, incluir um requisito de como isso pode ou deve ser testado.
|
||||
|
||||
A aplicação precisará ser implantada em algum lugar, vamos simplificar aqui e dizer que será um servidor, não importa onde, mas um servidor. Espera-se que isso seja acessado pelo cliente ou usuário final, dependendo da aplicação que foi criada.
|
||||
|
||||
Este servidor precisa ser executado em algum lugar, on-premises, em uma nuvem pública, sem servidor (Ok, eu fui longe demais, não cobriremos sem servidor, mas é uma opção e mais e mais empresas estão indo nessa direção). Alguém precisa criar e configurar esses servidores e prepará-los para a execução do aplicativo. Agora, esse elemento pode chegar a você como engenheiro DevOps para implantar e configurar esses servidores.
|
||||
|
||||
Esses servidores executam um sistema operacional e, em geral, isso será Linux, mas temos uma seção ou semana inteira onde abordamos alguns dos conhecimentos fundamentais que você deve obter aqui.
|
||||
|
||||
Também é provável que precisemos nos comunicar com outros serviços em nossa rede ou ambiente, portanto, também precisamos ter esse nível de conhecimento sobre rede e configuração, isso pode, em algum grau, também cair aos pés do engenheiro DevOps. Novamente, abordaremos isso com mais detalhes em uma seção dedicada, falando sobre todas as coisas DNS, DHCP, balanceamento de carga etc.
|
||||
|
||||
## Jack of all trades, Master of none
|
||||
_Essa é uma figura de linguagem americana, para se referir a uma pessoa que tem habilidades em diversas atividades, ao invés de estar focada em apenas uma. A melhor tradução ao pé da letra para Português seria "A pessoa que faz tudo e não é especialista em nada"_
|
||||
|
||||
Eu vou ser duro nesse ponto, você não precisa ser um especialista em rede ou infraestrutura, você precisa de um conhecimento básico de como colocar as coisas em funcionamento e conversando entre si, da mesma forma que talvez ter um conhecimento básico de uma linguagem de programação sem precisar ser um desenvolvedor. No entanto, você pode estar entrando nisso como um especialista em uma área e isso é uma ótima base para se adaptar a outras áreas.
|
||||
|
||||
Você também provavelmente não assumirá o gerenciamento desses servidores ou da aplicação diariamente.
|
||||
|
||||
Temos falado sobre servidores, mas a probabilidade é que sua aplicação seja desenvolvida para ser executada como contêineres, que ainda rodam em um servidor na maioria das vezes, mas você também precisará entender não apenas de virtualização, infraestrutura de nuvem como serviço (IaaS ), mas também a conteinerização. O foco nestes 90 dias será mais voltado para os contêineres.
|
||||
|
||||
## Visão geral de alto nível
|
||||
|
||||
De um lado temos nossos desenvolvedores criando novos recursos e funcionalidades (assim como correções de bugs) para a aplicação.
|
||||
|
||||
Do outro lado, temos algum tipo de ambiente, infraestrutura ou servidores que são configurados e gerenciados para executar esta aplicação e se comunicar com todos os seus serviços necessários.
|
||||
|
||||
A grande questão é como obtemos esses recursos e correções de bugs em nossos produtos e os disponibilizamos para esses usuários finais?
|
||||
|
||||
Como lançamos a nova versão da aplicação? Esta é uma das principais tarefas de um engenheiro DevOps, e o importante aqui não é apenas descobrir como fazer isso uma vez, mas precisamos fazer isso continuamente e de maneira automatizada e eficiente, que também precisa incluir testes!
|
||||
|
||||
É aqui que vamos terminar este dia de aprendizado, espero que tenha sido útil. Nos próximos dias, vamos nos aprofundar um pouco mais em mais algumas áreas do DevOps e, em seguida, nas seções que se aprofundam nas ferramentas, nos processos e nos benefícios deles.
|
||||
|
||||
## Recursos
|
||||
|
||||
Estou sempre aberto a adicionar recursos adicionais a esses arquivos README, pois estão aqui como uma ferramenta de aprendizado.
|
||||
|
||||
Meu conselho é assistir a todos os itens abaixo e espero que você também tenha captado algo do texto e das explicações acima.
|
||||
|
||||
- [O que é DevOps? - TechWorld with Nana](https://www.youtube.com/watch?v=0yWAtQ6wYNM)
|
||||
- [O que é DevOps? - GitHub YouTube](https://www.youtube.com/watch?v=kBV8gPVZNEE)
|
||||
- [O que é DevOps? - IBM YouTube](https://www.youtube.com/watch?v=UbtB4sMaaNM)
|
||||
- [O que é DevOps? - AWS](https://aws.amazon.com/devops/what-is-devops/)
|
||||
- [O que é DevOps? - Microsoft](https://docs.microsoft.com/en-us/devops/what-is-devops)
|
||||
|
||||
Se você chegou até aqui, saberá se é aqui que você quer estar ou não. Vejo você no [Dia 3](dia03.md).
|
87
pt-br/Days/day03.md
Normal file
87
pt-br/Days/day03.md
Normal file
@ -0,0 +1,87 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Foco na Aplicação - Dia 3'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Foco na Aplicação - Dia 3
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048825
|
||||
---
|
||||
|
||||
## Ciclo de vida do DevOps - Foco na Aplicação
|
||||
|
||||
À medida que continuarmos nas próximas semanas, em 100% das vezes encontraremos esses títulos (Desenvolvimento Contínuo, Teste, Implantação, Monitoramento) repetidamente. Se você está indo para a função de engenheiro DevOps, a repetibilidade será algo com a qual você se acostumará, mas melhorar constantemente a cada vez é outra coisa que mantém as coisas interessantes.
|
||||
|
||||
Neste momento, vamos dar uma olhada na visão de alto nível da aplicação do início ao fim e depois voltar novamente como um loop constante.
|
||||
|
||||
### Desenvolvimento
|
||||
|
||||
Vamos dar um novo exemplo de uma aplicação. Para começar não temos nada criado e talvez como desenvolvedor, você tenha que discutir com seu cliente ou usuário final os requisitos e criar algum tipo de plano ou requisitos para sua aplicação. Em seguida, precisamos criar a partir dos requisitos nossa nova aplicação.
|
||||
|
||||
Com relação às ferramentas nesta etapa, não há nenhum requisito real aqui além de escolher sua IDE e a linguagem de programação que você deseja usar para escrever sua aplicação.
|
||||
|
||||
Como engenheiro DevOps, lembre-se de que provavelmente não é você quem está criando este plano ou codificando a aplicação para o usuário final, este será um desenvolvedor habilidoso.
|
||||
|
||||
Mas também não faria mal para você poder ler parte do código para poder tomar as melhores decisões de infraestrutura no futuro para sua aplicação.
|
||||
|
||||
Mencionamos anteriormente que esta aplicação pode ser escrito em qualquer linguagem. É importante que isso seja mantido usando um sistema de controle de versão, isso é algo que também abordaremos em detalhes mais adiante e, em particular, mergulharemos no **Git**.
|
||||
|
||||
Também é provável que não seja um desenvolvedor trabalhando neste projeto, embora esse possa ser o caso, mesmo que as práticas recomendadas exigissem um repositório de código para armazenar e colaborar no código, isso pode ser privado ou público e pode ser implantando de forma hospedada ou privada. De maneira geral, você teria o **GitHub ou GitLab** sendo usado como um repositório de código. Mais uma vez, abordaremos isso como parte de nossa seção sobre **Git** mais adiante.
|
||||
|
||||
### Teste
|
||||
|
||||
Nesta etapa, temos os nossos requisitos e temos a nossa aplicação a ser desenvolvida. Mas precisamos ter certeza de que estamos testando nosso código em todos os diferentes ambientes que temos disponíveis para nós ou talvez especificamente para a linguagem de programação escolhida.
|
||||
|
||||
Essa etapa permite que o time de QA execute teste de bugs. De forma cada vez mais frequente vemos contêineres sendo usados para simular o ambiente de teste que, em geral, pode melhorar as despesas gerais de infraestrutura física ou em nuvem.
|
||||
|
||||
Essa etapa provavelmente também será automatizada como parte da próxima área, que é a Integração Contínua.
|
||||
|
||||
A capacidade de automatizar esse teste contra 10,100 ou mesmo 1000 engenheiros de controle de qualidade que precisam fazer isso manualmente fala por si, esses engenheiros podem se concentrar em outra coisa dentro da pilha para garantir que você esteja se movendo mais rápido e desenvolvendo mais funcionalidades em vez de testar bugs e software que tende a ser o atraso na maioria dos lançamentos de software tradicionais que usam uma metodologia em cascata.
|
||||
|
||||
### Integração
|
||||
|
||||
Muito importante, a integração está no meio do ciclo de vida do DevOps. É a prática na qual os desenvolvedores precisam confirmar alterações no código-fonte com mais frequência. Isso pode ser diário ou semanal.
|
||||
|
||||
A cada commit, sua aplicação pode passar pelas fases de teste automatizadas e isso permite a detecção antecipada de problemas ou bugs antes da próxima fase.
|
||||
|
||||
Agora você pode estar dizendo: "Mas nós não criamos aplicações, nós os compramos de um fornecedor de software". Não se preocupe, muitas empresas fazem isso e continuarão a fazer isso e será o fornecedor de software que está se concentrando nas três fases acima, mas talvez você ainda queira adotar a fase final, pois isso permitirá implantações mais rápidas e eficientes de suas implantações prontas para uso.
|
||||
|
||||
Eu também sugeriria que apenas ter esse conhecimento acima é muito importante, pois você pode comprar software de prateleira hoje, mas e amanhã ou no futuro... talvez no próximo trabalho?
|
||||
|
||||
### Implantação
|
||||
|
||||
Ok, então temos nossa aplicação construída e testada de acordo com os requisitos de nosso usuário final e agora precisamos seguir em frente e implantar essa aplicação em produção para nossos usuários finais consumirem.
|
||||
|
||||
Este é o estágio em que o código é implantado nos servidores de produção, agora é onde as coisas ficam extremamente interessantes e é onde o restante de nossos 86 dias se aprofunda nessas áreas. Porque aplicações diferentes exigem hardware ou configurações diferentes. É aqui que o **Gerenciamento de configuração de aplicações** e a **Infraestrutura como Código** podem desempenhar um papel fundamental no ciclo de vida do DevOps. Pode ser que sua aplicação seja **Containerizada**, mas também esteja disponível para execução em uma máquina virtual. Isso também nos leva a plataformas como o **Kubernetes**, que orquestrariam esses contêineres e garantiriam que você tivesse o estado desejado disponível para seus usuários finais.
|
||||
|
||||
Desses tópicos ousados, entraremos em mais detalhes nas próximas semanas para obter um melhor conhecimento básico sobre o que são e quando usá-los.
|
||||
|
||||
### Monitoramento
|
||||
|
||||
As coisas estão se movendo rapidamente aqui e temos nossa aplicação que estamos atualizando continuamente com novos recursos e funcionalidades. E ainda temos nossos testes para garantir que nenhum gremlin seja encontrado. Temos a aplicação em execução em nosso ambiente que pode manter continuamente a configuração e o desempenho necessários.
|
||||
|
||||
Mas agora precisamos ter certeza de que nossos usuários finais estão obtendo a experiência de que precisam. Aqui precisamos ter certeza de que o desempenho das nossas aplicações está sendo monitorado continuamente, esta etapa permitirá que seus desenvolvedores tomem melhores decisões sobre melhorias na aplicação em versões futuras para melhor atender os usuários finais.
|
||||
|
||||
Esta seção também é onde vamos capturar o ciclo de feedback sobre os recursos que foram implementados e como os usuários finais gostariam de torná-los melhores para eles.
|
||||
|
||||
A confiabilidade também é um fator chave aqui, no final das contas, queremos que nossa aplicação esteja disponível o tempo que for necessário. Isso leva a outras áreas de **observabilidade, segurança e gerenciamento de dados** que devem ser monitoradas continuamente e o feedback sempre pode ser usado para melhorar, atualizar e liberar a aplicação continuamente.
|
||||
|
||||
Algumas contribuições da comunidade aqui especificamente [@\_ediri](https://twitter.com/_ediri) mencionam que também fazem parte desse processo contínuo termos as equipes de FinOps envolvidas. As aplicações e dados estão sendo executados e armazenados em algum lugar que você deve monitorar continuamente para garantir que, se as coisas mudarem do ponto de vista dos recursos, seus custos não estejam causando grandes problemas financeiros em suas contas de Cloud.
|
||||
|
||||
Eu acho que também é um bom momento para trazer à tona o "Engenheiro DevOps" mencionado acima. Embora existam muitas posições de Engenheiro DevOps que as pessoas ocupam, essa não é a maneira ideal de posicionar o processo de DevOps. O que quero dizer é que, ao falar com outras pessoas da comunidade, o título de Engenheiro DevOps não deve ser o objetivo de ninguém, porque realmente qualquer posição deve adotar os processos de DevOps e a cultura explicada aqui. O DevOps deve ser usado em muitas posições diferentes, como engenheiro/arquiteto de tecnologias cloud native, administrador de virtualização, arquiteto/engenheiro de nuvem e administrador de infraestrutura. Isso é para citar alguns, mas o motivo para usar o Engenheiro DevOps acima foi realmente destacar o escopo do processo usado por qualquer uma das posições acima e muito mais.
|
||||
|
||||
## Recursos
|
||||
|
||||
Estou sempre aberto a adicionar recursos adicionais a esses arquivos README, pois está aqui como uma ferramenta de aprendizado.
|
||||
|
||||
Meu conselho é assistir a todos os itens abaixo e espero que você também tenha captado algo do texto e das explicações acima.
|
||||
|
||||
- [Desenvolvimento Contínuo](https://www.youtube.com/watch?v=UnjwVYAN7Ns) Também acrescentarei que isso é focado na indústria, mas a cultura enxuta pode ser seguida de perto com o DevOps.
|
||||
- [Testes Contínuos - IBM YouTube](https://www.youtube.com/watch?v=RYQbmjLgubM)
|
||||
- [Integração Contínua - IBM YouTube](https://www.youtube.com/watch?v=1er2cjUq1UI)
|
||||
- [Monitoramento Contínuo](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
|
||||
- [O fluxo remoto](https://www.notion.so/The-Remote-Flow-d90982e77a144f4f990c135f115f41c6)
|
||||
- [Fundação FinOps - O que é FinOps](https://www.finops.org/introduction/what-is-finops/)
|
||||
- [**Não gratuito** O projeto Fênix: Um romance sobre TI, DevOps e como ajudar sua empresa a vencer](https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/)
|
||||
|
||||
Se você chegou até aqui, saberá se é aqui que você quer estar ou não. Vejo você no [dia 4](day04.md).
|
99
pt-br/Days/day04.md
Normal file
99
pt-br/Days/day04.md
Normal file
@ -0,0 +1,99 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - DevOps & Agile - Dia 4'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - DevOps & Agile
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048700
|
||||
---
|
||||
|
||||
## DevOps & Agile
|
||||
|
||||
Você sabe a diferença entre DevOps e Agile? Eles foram formados como conceitos independentes. Mas agora os dois termos estão se fundindo.
|
||||
|
||||
Neste post, examinaremos as diferenças cruciais entre Agile e DevOps e descobriremos por que os dois estão tão conectados.
|
||||
|
||||
Acho que um bom lugar para começar, é entender um pouco mais sobre um ângulo comum que tenho visto no aprendizado dessa área é que sobre DevOps vs Agile, embora distintos possuem objetivos e processos semelhantes. Nesta seção, vou resumir isso.
|
||||
|
||||
Vamos começar com as definições.
|
||||
|
||||
### Desenvolvimento ágil
|
||||
|
||||
Agile é uma abordagem que se concentra em fornecer pequenos resultados mais rapidamente, em vez de liberar uma grande interação do produto; o software é desenvolvido em iterações. A equipe lança uma nova versão a cada semana ou mês com atualizações incrementais. O objetivo final do Agile é oferecer uma experiência ideal para os usuários finais.
|
||||
|
||||
### DevOps
|
||||
|
||||
Nos últimos dias, abordamos isso com algumas maneiras diferentes de descrever os objetivos finais do DevOps. DevOps geralmente descreve o desenvolvimento de software
|
||||
e práticas de entrega baseadas na cooperação entre desenvolvedores de software e especialistas em operações. Os principais benefícios do DevOps são fornecer um processo de desenvolvimento simplificado e minimizar a falta de comunicação.
|
||||
|
||||
## Qual é a diferença entre Agile e DevOps?
|
||||
|
||||
A diferença está principalmente nas preocupações. Agile e DevOps têm preocupações diferentes, mas estão ajudando um ao outro. O Agile quer iteração curta, o que só é possível com a automação que o DevOps traz. A Agile quer que o cliente experimente uma versão específica e dê feedback rapidamente, o que só é possível se o DevOps tornar a criação de um novo ambiente algo simples.
|
||||
|
||||
### Participantes diferentes
|
||||
|
||||
O Agile se concentra na otimização da comunicação entre usuários finais e desenvolvedores, enquanto o DevOps visa desenvolvedores e operações, membros da equipe. Poderíamos dizer que o ágil é orientado para o lado externo (os clientes), enquanto o DevOps é um conjunto de práticas internas.
|
||||
|
||||
### Equipe
|
||||
|
||||
Agile geralmente se aplica a desenvolvedores de software e gerentes de projeto. As competências dos engenheiros de DevOps estão na interseção de desenvolvimento, controle de qualidade (garantia de qualidade) e operações, pois estão envolvidos em todas as etapas do ciclo do produto e fazem parte da equipe Agile.
|
||||
|
||||
### Estruturas Aplicadas
|
||||
|
||||
O Agile tem muitas estruturas de gerenciamento para obter flexibilidade e transparência: Scrum > Kanban > Lean > Extreme > Crystal > Dynamic > Feature-Driven. O DevOps se concentra na abordagem de desenvolvimento em colaboração, mas não oferece metodologias específicas. No entanto, DevOps promove práticas como Infraestrutura como Código, Arquitetura como Código, Monitoramento, Self-Healing, automação de testes de ponta a ponta...
|
||||
|
||||
### Feedback
|
||||
|
||||
No Agile, a principal fonte de feedback é o usuário final, enquanto no DevOps o feedback vem das partes interessadas e da própria equipe tem maior prioridade.
|
||||
|
||||
### Áreas-alvo
|
||||
|
||||
O Agile se concentra mais no desenvolvimento de software do que na implantação e manutenção. O DevOps também se concentra no desenvolvimento de software, mas seus valores e ferramentas também abrangem estágios de implantação e pós-lançamento, como monitoramento, alta disponibilidade, segurança e proteção de dados.
|
||||
|
||||
### Documentação
|
||||
|
||||
O Agile prioriza a flexibilidade e as tarefas em relação a documentação e o monitoramento. O DevOps, por outro lado, considera a documentação do projeto como um dos componentes essenciais do projeto.
|
||||
|
||||
### Riscos
|
||||
|
||||
Os riscos ágeis derivam da flexibilidade da metodologia. Projetos ágeis são difíceis de prever ou avaliar, pois as prioridades e os requisitos estão mudando continuamente.
|
||||
|
||||
Os riscos de DevOps derivam de um mal-entendido do termo e da falta de ferramentas adequadas. Algumas pessoas veem o DevOps como uma coleção de software para implantação e integração contínua que não altera a estrutura subjacente do processo de desenvolvimento.
|
||||
|
||||
### As ferramentas usadas
|
||||
|
||||
As ferramentas ágeis são focadas na colaboração de comunicação gerencial, métricas e processamento de feedback. As ferramentas ágeis mais populares incluem JIRA, Trello, Slack, Zoom, SurveyMonkey e outras.
|
||||
|
||||
DevOps usa ferramentas para comunicação de equipe, desenvolvimento de software, implantação e integração como Jenkins, GitHub Actions, BitBucket, etc. Embora ágil e DevOps tenham focos e escopos ligeiramente diferentes, os valores-chave são quase idênticos, portanto, você pode combinar os dois.
|
||||
|
||||
## Junte tudo… boa ideia ou não? Vamos discutir?
|
||||
|
||||
A combinação de Agile e DevOps traz os seguintes benefícios:
|
||||
|
||||
- Gestão flexível e tecnologia poderosa.
|
||||
- As práticas ágeis ajudam as equipes de DevOps a comunicar suas prioridades com mais eficiência.
|
||||
- O custo de automação que você precisa pagar por suas práticas de DevOps é justificado por sua exigência ágil de implantação rápida e frequente.
|
||||
- Leva ao fortalecimento: a equipe adotando práticas ágeis melhorará a colaboração, aumentará a motivação da equipe e diminuirá as taxas de rotatividade de funcionários.
|
||||
- Como resultado, você obtém uma melhor qualidade do produto.
|
||||
|
||||
O Agile permite voltar aos estágios anteriores de desenvolvimento do produto para corrigir erros e evitar o acúmulo de dívida técnica. Para adotar ágil e DevOps
|
||||
simultaneamente basta seguir estes 7 passos:
|
||||
|
||||
1. Unir as equipes de desenvolvimento e operação.
|
||||
2. Crie equipes de build e execução, todas as preocupações operacionais e de desenvolvimento são discutidas por toda a equipe de DevOps.
|
||||
3. Mude sua abordagem aos sprints e atribua classificações de prioridade para oferecer tarefas de DevOps que tenham o mesmo valor das tarefas de desenvolvimento. Incentive as equipes de desenvolvimento e operações a trocarem suas opiniões sobre o fluxo de trabalho de outras equipes e possíveis problemas.
|
||||
4. Incluir QA em todas as etapas de desenvolvimento.
|
||||
5. Escolha as ferramentas certas.
|
||||
6. Automatize tudo o que puder.
|
||||
7. Meça e controle usando resultados numéricos tangíveis.
|
||||
|
||||
O que você acha? Você tem visões diferentes? Eu quero ouvir de desenvolvedores, operações, controle de qualidade ou qualquer pessoa que tenha um melhor entendimento de Agile e DevOps que possa passar comentários e feedback sobre isso
|
||||
|
||||
### Recursos
|
||||
|
||||
- [DevOps para Desenvolvedores – Um dia na vida de um: DevOps Engineer em 2021](https://www.youtube.com/watch?v=2JymM0YoqGA)
|
||||
- [3 coisas que eu gostaria de saber como engenheiro DevOps](https://www.youtube.com/watch?v=udRNM7YRdY4)
|
||||
- [Como se tornar um engenheiro de DevOps - feat. Shawn Powers](https://www.youtube.com/watch?v=kDQMjAQNvY4)
|
||||
|
||||
Se você chegou até aqui, saberá se é aqui que você quer estar ou não. Vejo você no [Dia 5](day05.md).
|
85
pt-br/Days/day05.md
Normal file
85
pt-br/Days/day05.md
Normal file
@ -0,0 +1,85 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Planejamento > Codificação > Build > Testes > Release > Deploy > Operação > Monitoramento > - Dia 5'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - PlanPlanejamento > Codificação > Build > Testes > Release > Deploy > Operação > Monitoramento >
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048830
|
||||
---
|
||||
|
||||
## Planejamento > Codificação > Build > Testes > Release > Deploy > Operação > Monitoramento
|
||||
|
||||
Hoje vamos nos concentrar nas etapas individuais do início ao fim e no ciclo contínuo de uma aplicação no mundo DevOps.
|
||||
![DevOps](Images/Day5_DevOps8.png)
|
||||
|
||||
### Planejamento
|
||||
|
||||
Tudo começa com o processo de planejamento, é onde a equipe de desenvolvimento se reúne e descobre quais tipos de recursos e correções de bugs serão lançados em seu próximo sprint. Esta é uma oportunidade para você como engenheiro DevOps se envolver e aprender com que tipo de coisa virá ao seu caminho e também para influenciar nas decisões deles. Ajudá-los a trabalhar na infraestrutura que você construiu ou orientá-los para algo que funcionará melhor para eles caso não estejam nesse caminho e, portanto, uma coisa importante a destacar aqui é que os desenvolvedores ou a equipe de engenharia de software são seu cliente como engenheiro DevOps, então esta é sua oportunidade de trabalhar com seu cliente antes que ele siga um caminho ruim.
|
||||
|
||||
### Codificação
|
||||
|
||||
Agora que a sessão de planejamento terminou, eles vão começar a escrever o código. Você pode não estar muito envolvido com isso, mas aqui é um dos lugares em que você pode se envolver com isso. Sempre que eles estiverem escrevendo código, você pode ajudá-los a entender melhor a infraestrutura, então, se eles souberem quais serviços estão disponíveis e como conversar melhor com esses serviços, eles farão isso e, quando terminarem, mesclarão esse código no repositório.
|
||||
|
||||
### Build
|
||||
|
||||
É aqui que iniciaremos o primeiro de nossos processos de automação, porque pegaremos o código deles e o construiremos juntos. Dependendo de qual linguagem eles estão usando, pode estar compilando ou pode estar criando uma imagem docker a partir desse código. De qualquer forma, vamos passar por esse processo usando nosso pipeline ci/cd.
|
||||
|
||||
## Testes
|
||||
|
||||
Depois da fase de construção (build), vamos executar alguns testes nele. Agora a equipe de desenvolvimento geralmente escreve o teste, você pode ter algumas informações sobre quais testes são escritos, mas precisamos executar esses testes. O teste é uma maneira de tentar minimizar a introdução de problemas em produção, obviamente não temos como garantir isso, mas queremos chegar o mais próximo possível de garantir que não serão inseridos novos bugs e não serão quebradas coisas que estavam funcionando.
|
||||
|
||||
## Release
|
||||
|
||||
Assim que os testes passarem, faremos o processo de release (lançamento) e, dependendo novamente do tipo de aplicação em que você está trabalhando, isso pode não ser uma etapa. Você sabe que o código pode estar no repositório do GitHub ou no repositório do git, ou onde quer que ele esteja, mas pode ser o processo de pegar seu código compilado ou a imagem do docker que você criou e colocá-la em um registro ou repositório onde está acessível por seus servidores de produção para o processo de deploy (implantação).
|
||||
|
||||
## Deploy
|
||||
|
||||
Deploy, é o que fazemos em seguida, porque a implantação é como o final do jogo de tudo isso, porque as implantações (deploys) são quando colocamos o código em produção. Enquanto não fazemos isso é que nossa empresa percebe o valor de todo o esforço e trabalho duro que você e a equipe de engenharia de software colocaram neste produto até este ponto.
|
||||
|
||||
## Operação
|
||||
|
||||
Uma vez implantado, vamos operá-lo. E operá-lo pode envolver algo como você começar a receber ligações de seus clientes que estão todos irritados porque o site está lento ou a aplicação está lenta, então você precisa descobrir por quê. Em seguida, possivelmente, construa o dimensionamento automático que você sabe lidar, aumente o número de servidores disponíveis durante os períodos de pico e diminua o número de servidores durante os períodos fora do pico de qualquer maneira. Outra coisa operacional que você faz é incluir como um loop de feedback da produção de volta para sua equipe de operações informando sobre os principais eventos que aconteceram na produção, fazer rollback do deploy. Isso pode ou não ser automatizado, dependendo do seu ambiente, o objetivo é sempre automatizá-lo quando possível. Existem alguns ambientes onde você possivelmente precisa fazer algumas etapas antes de estar pronto para fazer isso, mas idealmente você deseja implantar automaticamente como parte da sua automação. Porém caso você esteja fazendo isso, pode ser uma boa idéia incluir em suas etapas operacionais algum tipo de notificação para que sua equipe de operações saiba que uma implantação aconteceu.
|
||||
|
||||
## Monitoramento
|
||||
|
||||
All of the above parts lead to the final step because you need to have monitoring, especially around operational issues auto-scaling troubleshooting like you don't know
|
||||
there's a problem if you don't have monitoring in place to tell you that there's a problem so some of the things you might build monitoring for are memory utilization CPU utilization disk space, API endpoint, response time, how quickly that endpoint is responding and a big part of that as well is logs. Logs give developers the ability to see what is happening without having to access production systems.
|
||||
|
||||
## Rinse & Repeat
|
||||
|
||||
Once that's in place you go right back to the beginning to the planning stage and go through the whole thing again
|
||||
|
||||
## Continuous
|
||||
|
||||
Many tools help us achieve the above continuous process, all this code and the ultimate goal of being completely automated, cloud infrastructure or any environment is often described as Continuous Integration/ Continuous Delivery/Continous Deployment or “CI/CD” for short. We will spend a whole week on CI/CD later on in the 90 Days with some examples and walkthroughs to grasp the fundamentals.
|
||||
|
||||
### Continuous Delivery
|
||||
|
||||
Continuous Delivery = Plan > Code > Build > Test
|
||||
|
||||
### Continuous Integration
|
||||
|
||||
This is effectively the outcome of the Continuous Delivery phases above plus the outcome of the Release phase. This is the case for both failure and success but this is fed back into continuous delivery or moved to Continuous Deployment.
|
||||
|
||||
Continuous Integration = Plan > Code > Build > Test > Release
|
||||
|
||||
### Continuous Deployment
|
||||
|
||||
If you have a successful release from your continuous integration then move to Continuous Deployment which brings in the following phases
|
||||
|
||||
CI Release is Success = Continuous Deployment = Deploy > Operate > Monitor
|
||||
|
||||
You can see these three Continuous notions above as the simple collection of phases of the DevOps Lifecycle.
|
||||
|
||||
This last bit was a bit of a recap for me on Day 3 but think this makes things clearer for me.
|
||||
|
||||
### Resources
|
||||
|
||||
- [DevOps for Developers – Software or DevOps Engineer?](https://www.youtube.com/watch?v=a0-uE3rOyeU)
|
||||
- [Techworld with Nana -DevOps Roadmap 2022 - How to become a DevOps Engineer? What is DevOps?](https://www.youtube.com/watch?v=9pZ2xmsSDdo&t=125s)
|
||||
- [How to become a DevOps Engineer in 2021 - DevOps Roadmap](https://www.youtube.com/watch?v=5pxbp6FyTfk)
|
||||
|
||||
If you made it this far then you will know if this is where you want to be or not.
|
||||
|
||||
See you on [Day 6](day06.md).
|
169
pt-br/README.md
Normal file
169
pt-br/README.md
Normal file
@ -0,0 +1,169 @@
|
||||
|
||||
# 90DaysOfDevOps
|
||||
|
||||
<p align="center">
|
||||
<img src="../logo.png?raw=true" alt="90DaysOfDevOps Logo" width="50%" height="50%" />
|
||||
</p>
|
||||
|
||||
Versão em Portugês | [中文版本](zh_cn/README.md) | [繁體中文版本](zh_tw/README.md)| [日本語版](ja/README.md) | [Wersja Polska](pl/README.md) | [Tiếng Việt](vi/README.md)
|
||||
|
||||
Este repositório é usado para documentar minha jornada para obter um melhor conhecimento básico de "DevOps". Estarei começando esta jornada no dia 1º de janeiro de 2022, mas a ideia é que levemos 90 dias, o que acontece de 1º de janeiro a 31 de março.
|
||||
|
||||
A razão para documentar esses dias é para que outros possam tirar algum proveito disso e também melhorar os recursos.
|
||||
|
||||
O objetivo é levar 90 dias, 1 hora por dia, para abordar mais de 13 áreas de "DevOps" para um conhecimento básico.
|
||||
|
||||
Isso **não abrangerá todas as coisas** sobre "DevOps", mas abrangerá as áreas que considero que beneficiarão meu aprendizado e compreensão em geral.
|
||||
|
||||
[![ko-fi](https://ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/N4N33YRCS)
|
||||
|
||||
A maneira mais rápida de entrar em contato será via Twitter, meu contato é [@MichaelCade1](https://twitter.com/MichaelCade1)
|
||||
|
||||
## Progresso
|
||||
|
||||
- [✔️] ♾️ 1 > [Introdução](Days/day01.md)
|
||||
|
||||
### O que é e por que usamos DevOps
|
||||
|
||||
- [✔️] ♾️ 2 > [Responsabilidades de um engenheiro de DevOps](Days/day02.md)
|
||||
- [✔️] ♾️ 3 > [Ciclo de vida do DevOps - Foco no aplicativo](Days/day03.md)
|
||||
- [✔️] ♾️ 4 > [DevOps & Agile](Days/day04.md)
|
||||
- [✔️] ♾️ 5 > [Planejamento > Codificação > Build > Teste > Release > Deployment > Operação > Monitoramento >](Days/day05.md)
|
||||
- [✔️] ♾️ 6 > [DevOps - As histórias reais](Days/day06.md)
|
||||
|
||||
### Aprendendo uma linguagem de programação
|
||||
|
||||
- [✔️] ⌨️ 7 > [O panorama geral: DevOps & Aprendizado de uma linguagem de programação](Days/day07.md)
|
||||
- [✔️] ⌨️ 8 > [Configurando seu ambiente DevOps para Go & "Hello World"](Days/day08.md)
|
||||
- [✔️] ⌨️ 9 > [Vamos explicar o código "Hello World"](Days/day09.md)
|
||||
- [✔️] ⌨️ 10 > [O workspace Go & compilação & execução de código](Days/day10.md)
|
||||
- [✔️] ⌨️ 11 > [Variáveis, Constantes & Tipos de Dados](Days/day11.md)
|
||||
- [✔️] ⌨️ 12 > [Obtendo a entrada do usuário com ponteiros e um programa finalizado](Days/day12.md)
|
||||
- [✔️] ⌨️ 13 > [Tweet sey progresso com nosso novo aplicativo](Days/day13.md)
|
||||
|
||||
### Conhecendo o básico do Linux
|
||||
|
||||
- [✔️] 🐧 14 > [O panorama geral: DevOps e Linux](Days/day14.md)
|
||||
- [✔️] 🐧 15 > [Comandos Linux para DevOps (Na verdade para todo mundo)](Days/day15.md)
|
||||
- [✔️] 🐧 16 > [Gerenciando seu sistema Linux, sistema de arquivos & storage](Days/day16.md)
|
||||
- [✔️] 🐧 17 > [Editores de texto - nano vs vim](Days/day17.md)
|
||||
- [✔️] 🐧 18 > [SSH & Servidor Web (LAMP)](Days/day18.md)
|
||||
- [✔️] 🐧 19 > [Automatize tarefas com scripts bash](Days/day19.md)
|
||||
- [✔️] 🐧 20 > [Configuração da estação de trabalho do dsenvolvedor - Com tudo perfeito](Days/day20.md)
|
||||
|
||||
### Compreendendo redes
|
||||
|
||||
- [✔️] 🌐 21 > [O panorama geral: DevOps e Redes](Days/day21.md)
|
||||
- [✔️] 🌐 22 > [O Modelo OSI - As 7 Camadas](Days/day22.md)
|
||||
- [✔️] 🌐 23 > [Protocolos de rede](Days/day23.md)
|
||||
- [✔️] 🌐 24 > [Automação de Rede](Days/day24.md)
|
||||
- [✔️] 🌐 25 > [Python para automação de rede](Days/day25.md)
|
||||
- [✔️] 🌐 26 > [Construindo nosso laboratório](Days/day26.md)
|
||||
- [✔️] 🌐 27 > [Praticando Python & Redes](Days/day27.md)
|
||||
|
||||
### Atenha-se a um provedor de nuvem
|
||||
|
||||
- [✔️] ☁️ 28 > [O panorama geral: DevOps e a nuvem](Dias/dia28.md)
|
||||
- [✔️] ☁️ 29 > [Fundamentos do Microsoft Azure](Dias/dia29.md)
|
||||
- [✔️] ☁️ 30 > [Modelos de Segurança do Microsoft Azure](Dias/dia30.md)
|
||||
- [✔️] ☁️ 31 > [Modelos de Computação do Microsoft Azure](Dias/dia31.md)
|
||||
- [✔️] ☁️ 32 > [Modelos de armazenamento e banco de dados do Microsoft Azure](Days/day32.md)
|
||||
- [✔️] ☁️ 33 > [Modelos de Rede do Microsoft Azure + Gerenciamento do Azure](Days/day33.md)
|
||||
- [✔️] ☁️ 34 > [Cenários práticos do Microsoft Azure](Dias/dia34.md)
|
||||
|
||||
### Use o Git de forma eficaz
|
||||
|
||||
- [✔️] 📚 35 > [O panorama geral: Git - Controle de Versão](Days/day35.md)
|
||||
- [✔️] 📚 36 > [Instalando e configurando o Git](Days/day36.md)
|
||||
- [✔️] 📚 37 > [Conhecendo o Git](Dias/dia37.md)
|
||||
- [✔️] 📚 38 > ["Staging" e "Changing"](Dias/dia38.md)
|
||||
- [✔️] 📚 39 > [Visualização, "unstaging", descarte e restauração](Dias/dia39.md)
|
||||
- [✔️] 📚 40 > [Rede Social para código](Dias/dia40.md)
|
||||
- [✔️] 📚 41 > [O fluxo de trabalho do código aberto](Days/day41.md)
|
||||
|
||||
### Recipientes
|
||||
|
||||
- [✔️] 🏗️ 42 > [O panorama geral: Contêineres](Dias/dia42.md)
|
||||
- [✔️] 🏗️ 43 > [O que é o Docker e preparação da instalação](Days/day43.md)
|
||||
- [✔️] 🏗️ 44 > [Imagens Docker & Prática com Docker Desktop](Days/day44.md)
|
||||
- [✔️] 🏗️ 45 > [A anatomia de uma imagem do Docker](Days/day45.md)
|
||||
- [✔️] 🏗️ 46 > [Docker Compose](Days/day46.md)
|
||||
- [✔️] 🏗️ 47 > [Rede & Segurança com Docker](Days/day47.md)
|
||||
- [✔️] 🏗️ 48 > [Alternativas ao Docker](Dias/dia48.md)
|
||||
|
||||
### Kubernetes
|
||||
|
||||
- [✔️] ☸ 49 > [O panorama geral: Kubernetes](Dias/dia49.md)
|
||||
- [✔️] ☸ 50 > [Escolhendo sua plataforma Kubernetes](Dias/dia50.md)
|
||||
- [✔️] ☸ 51 > [Implantando seu primeiro cluster Kubernetes](Days/day51.md)
|
||||
- [✔️] ☸ 52 > [Configurando um cluster Kubernetes com múltiplos nós](Days/day52.md)
|
||||
- [✔️] ☸ 53 > [Visão geral do Rancher - Prática](Dias/dia53.md)
|
||||
- [✔️] ☸ 54 > [Implantação de aplicações com Kubernetes](Dias/dia54.md)
|
||||
- [✔️] ☸ 55 > ["State" e "Ingress" no Kubernetes](Dias/dia55.md)
|
||||
|
||||
### Aprenda a infraestrutura como código
|
||||
|
||||
- [✔️] 🤖 56 > [O panorama geral: IaC](Dias/dia56.md)
|
||||
- [✔️] 🤖 57 > [Uma introdução ao Terraform](Days/day57.md)
|
||||
- [✔️] 🤖 58 > [Linguagem de Configuração do HashiCorp (HCL)](Days/day58.md)
|
||||
- [✔️] 🤖 59 > [Crie uma VM com Terraform & Variáveis](Days/day59.md)
|
||||
- [✔️] 🤖 60 > [Contêineres Docker, Provisionadores & Módulos](Days/day60.md)
|
||||
- [✔️] 🤖 61 > [Kubernetes e múltiplos ambientes](Dias/dia61.md)
|
||||
- [✔️] 🤖 62 > [Testes, ferramentas e alternativas](Dias/dia62.md)
|
||||
|
||||
### Automatize o gerenciamento de configuração
|
||||
|
||||
- [✔️] 📜 63 > [O panorama gera: Gerência de Configuração](Days/day63.md)
|
||||
- [✔️] 📜 64 > [Ansible: Primeiros passos](Days/day64.md)
|
||||
- [✔️] 📜 65 > [Manual do Ansible](Dias/dia65.md)
|
||||
- [✔️] 📜 66 > [Manual do Ansible - Continuação...](Dias/dia66.md)
|
||||
- [✔️] 📜 67 > [Usando funções e implantando um balanceador de carga](Days/day67.md)
|
||||
- [✔️] 📜 68 > ["Tags", Variáveis, Inventário & Servidor de Configuração de Banco de Dados](Days/day68.md)
|
||||
- [✔️] 📜 69 > [Todas as outras coisas sobre Ansible - "Automation Controller", "AWX", "Vault"](Days/day69.md)
|
||||
|
||||
### Crie pipelines de CI/CD
|
||||
|
||||
- [✔️] 🔄 70 > [O panorama gera: Pipelines de CI/CD](Dias/dia70.md)
|
||||
- [✔️] 🔄 71 > [O que é Jenkins?](Dias/dia71.md)
|
||||
- [✔️] 🔄 72 > [Colocando as mãos no Jenkins](Days/day72.md)
|
||||
- [✔️] 🔄 73 > [Construindo um pipeline do Jenkins](Days/day73.md)
|
||||
- [✔️] 🔄 74 > ["Hello World" - Jenkinsfile App Pipeline](Days/day74.md)
|
||||
- [✔️] 🔄 75 > [Visão geral das ações do GitHub](Days/day75.md)
|
||||
- [✔️] 🔄 76 > [Visão geral do ArgoCD](Dias/dia76.md)
|
||||
|
||||
### Monitoramento, gerenciamento de log e visualização de dados
|
||||
|
||||
- [✔️] 📈 77 > [O panorama geral: Monitoramento](Days/day77.md)
|
||||
- [✔️] 📈 78 > [Prática com ferramentas de monitoramento](Dias/dia78.md)
|
||||
- [✔️] 📈 79 > [O panorama geral: gerenciamento de logs](Dias/dia79.md)
|
||||
- [✔️] 📈 80 > [ELK Stack](Dias/dia80.md)
|
||||
- [✔️] 📈 81 > [Fluentd & FluentBit](Dias/dia81.md)
|
||||
- [✔️] 📈 82 > [EFK Stack](Dias/dia82.md)
|
||||
- [✔️] 📈 83 > [Visualização de Dados - Grafana](Dias/dia83.md)
|
||||
|
||||
### Armazene e proteja seus dados
|
||||
|
||||
- [✔️] 🗃️ 84 > [O panorama geral: Gerenciamento de dados](Dias/dia84.md)
|
||||
- [✔️] 🗃️ 85 > [Serviços de Dados](Dias/dia85.md)
|
||||
- [✔️] 🗃️ 86 > [Fazer backup de todas as plataformas](Dias/dia86.md)
|
||||
- [✔️] 🗃️ 87 > [Prática de backup e recuperação](Dias/dia87.md)
|
||||
- [✔️] 🗃️ 88 > [Backups focados em aplicações](Dias/dia88.md)
|
||||
- [✔️] 🗃️ 89 > [Recuperação de desastres](Dias/dia89.md)
|
||||
- [✔️] 🗃️ 90 > [Mobilidade de dados e aplicações](Dias/dia90.md)
|
||||
|
||||
## Licença
|
||||
|
||||
Amparado sob: [![CC BY-NC-SA 4.0][cc-by-nc-sa-shield]][cc-by-nc-sa]
|
||||
|
||||
Esta obra está licenciada sob
|
||||
[Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License][cc-by-nc-sa].
|
||||
|
||||
[![CC BY-NC-SA 4.0][cc-by-nc-sa-image]][cc-by-nc-sa]
|
||||
|
||||
## Histórico de estrelas
|
||||
|
||||
[![Star History Chart](https://api.star-history.com/svg?repos=MichaelCade/90DaysOfDevOps&type=Timeline)](https://star-history.com/#MichaelCade/90DaysOfDevOps&Timeline)
|
||||
|
||||
[cc-by-nc-sa]: http://creativecommons.org/licenses/by-nc-sa/4.0/
|
||||
[cc-by-nc-sa-image]: https://licensebuttons.net/l/by-nc-sa/4.0/88x31.png
|
||||
[cc-by-nc-sa-shield]: https://img.shields.io/badge/License-CC%20BY--NC--SA%204.0-lightgrey.svg
|
71
vi/Days/day07.md
Normal file
71
vi/Days/day07.md
Normal file
@ -0,0 +1,71 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Bức tranh toàn cảnh: DevOps & Học một ngôn ngữ lập trình'
|
||||
published: false
|
||||
description: '90DaysOfDevOps - Bức tranh toàn cảnh: DevOps & Học một ngôn ngữ lập trình'
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048856
|
||||
---
|
||||
|
||||
## Bức tranh toàn cảnh: DevOps & Học một ngôn ngữ lập trình
|
||||
|
||||
Nói một cách công bằng, bạn phải biết ít nhất một ngôn ngữ lập trình ở mức độ cơ bản để trở thành một kỹ sư DevOps thành công. Tôi muốn dành phần đầu tiên để tìm hiểu lý do tại sao điều này lại quan trọng như vậy và hi vọng rằng đến sau ngày hôm này (hoặc sau tuần thứ 2 này) bạn sẽ hiểu rõ hơn về lý do, cách thức và những gì bạn có thể làm để thúc đẩy việc học của mình.
|
||||
|
||||
Nếu tôi hỏi trên các mạng xã hội rằng bạn có cần kỹ năng lập trình cho các vai trò liên quan tới DevOps hay không, câu trả lời khả năng cao là "có". Hãy cho tôi biết nếu bạn không nghĩ như vậy. Nhưng câu hỏi lớn hơn và không có một câu trả lời rõ ràng là ngôn ngữ lập trình nào? Câu trả lời phổ biến nhất có thể là Python hoặc gần đây, ngành càng có nhiều người nói rằng bạn nên học Golang hoặc bạn cần phải học Go.
|
||||
|
||||
Với những câu trả lời đó, tôi có thể hiểu được rằng để trở thành một kỹ sư DevOps thành công bạn cần có một kiến thức tốt về kỹ năng lập trình. Nhưng chúng ta phải hiểu lý do tại sao nó lại cần thiết để chọn một con đường phù hợp.
|
||||
|
||||
## Hiểu tại sao bạn cần học một ngôn ngữ lập trình
|
||||
|
||||
Lý do mà Python và Go thường được khuyến nghị cho các kỹ sư DevOps là có rất nhiều công cụ DevOps được viết bằng Python hoặc Go, điều này rất quan trọng nếu bạn đang chuẩn bị xây dựng các công cụ DevOps và nó quyết định những gì bạn nên học để có lợi nhất mình. Nếu bạn đang muốn xây dựng hoặc tham gia một nhóm xây dựng các công cụ DevOps, thì việc học cùng một ngôn ngữ là rất hợp lý. Nếu bạn muốn tiếp cận với Kubernetes hoặc Containers thì khả năng cao lựa chọn của bạn sẽ là Go. Đối với tôi, công ty tôi đang làm việc (Kasten by Veeam) nằm trong hệ sinh thái Cloud-Native tập trung vào quản lý dữ liệu cho Kubernetes và mọi thứ được viết bằng Go.
|
||||
|
||||
Tuy nhiên, trong trường hợp nếu bạn không có một lý do rõ ràng như vậy ví dụ như bạn đang là sinh viên hoặc đang chuẩn bị cho một bước mới trong sự nghiệp của bạn thì tôi nghĩ bạn nên chọn thứ gì đó phù hợp với ứng dụng hoặc stack công nghệ mà bạn muốn làm việc cùng.
|
||||
|
||||
Hãy nhớ rằng chúng ta không muốn trở thành một nhà phát triển phần mềm ở đây mà chỉ muốn hiểu thêm về ngôn ngữ lập trình để có thể đọc và hiểu những công cụ đó đang làm gì từ đó có thể triển khai và cải thiện những thứ khác.
|
||||
|
||||
Một điều quan trọng cần biết nữa là cách bạn tương tác, làm việc với các công cụ DevOps, đó có thể là Kasten K10 hoặc Terraform và HCL. Chúng ta gọi chúng là các tệp (file) cầu hình và đó là cách bạn tương tác với các công cụ DevOps và biến mọi thứ thành hiện thực, thông thược sẽ là các file YAML (Chúng ta sẽ tìm hiểu về YAML ở cuối tuần này)
|
||||
|
||||
## Có phải tôi đã thuyết phục bản thân không học một ngôn ngữ lập trình?
|
||||
|
||||
Hầu hết nó sẽ tuỳ thuộc vào vai trò, bạn sẽ giúp các nhóm kỹ sư triển khai DevOps trong quy trình làm việc của họ, thực hiện nhiều thử nghiệm trên ứng dụng và đảm bảo quy trình được xây dựng phù hợp với các nguyên tắc DevOps mà chúng ta đã đề cập trong những ngày đầu tiên. Tuy nhiên, trong thực tế, dường như phần lớn thời gian thường sẽ là việc khắc phục sự cố về hiệu suất ứng dụng và tương tự như vậy. Điều này quay trở lại quan điểm dầu tiên, ngôn ngữ lập trình mình cần biết có phải là ngôn ngữ mà ứng dụng được viết? Nếu ứng dụng được viết bằng NodeJS thì bạn sẽ không giúp ích được nhiều nếu bạn biết biết về Go hoặc Python.
|
||||
|
||||
## Tại sao là Go?
|
||||
|
||||
Tại sao Golang là ngôn ngữ lập trình tiếp theo cho DevOps và trở thành ngôn ngữ lập trình rất phổ biến trong những năm gần đây. Theo khảo sát của [StackOverflow cho năm 2021](https://insights.stackoverflow.com/survey/2021#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages), Go là ngôn ngữ lập trình đứng thứ 4 trong các ngôn ngữ lập trình, scripting và markup trong khi Python đứng thứ 1 nhưng hãy nghe tôi trình bày.
|
||||
|
||||
Tôi đã đề cập đến một số công cụ và nền tảng DevOps được biết đến nhiều nhất được viết bằng Go như Kubernetes, Docker, Grafana và Prometheus.
|
||||
|
||||
Những đặc điểm của Go khiến nó trở nên phù hợp với DevOps là gì?
|
||||
|
||||
## Xây dựng và Triển khai với Go
|
||||
|
||||
Một lợi thế của việc sử dụng ngôn ngữ như Python trong vai trò DevOps là mã được thông dịch và bạn không cần phải biên dịch trước khi chạy các chương trình sử dụng Python. Đặc biệt với các tác vụ tự động hoá nhỏ, bạn không muốn mất thời gian cho quá trình biên dịch, dù vậy Go là một ngôn ngữ lập trình biên dịch và **Go biên dịch trực tiếp ra mã máy**. Go cũng nổi tiếng với tốc độ biên dịch nhanh.
|
||||
|
||||
## Go với Python dành cho DevOps
|
||||
|
||||
Các chương trình Go được liên kết tĩnh, điều này có nghĩa khi bạn biên dịch một chương trình viết bằng Go, mọi thứ đều được bao gồm trong một tệp thực thi nhị phân duy nhất và không cần cài đặt thêm các phụ thuộc (dependencies) và thư viện bên ngoài trên các máy chủ. Điều này giúp cho việc triển khai các chương trình viết bằng Go dễ dàng hơn so với các chương trình Python sử dụng các thư viện bên ngoài nên bạn phải đảm bảo các thư việc được cài đặt trên máy chủ trước khi bạn có thể chạy chương trình.
|
||||
|
||||
Go là một ngôn ngữ độc lập với nền tảng, có nghĩa là bạn có thể tạo ra các tệp thực thi nhị phân cho tất cả các hệ điền hành như Linux, Windows, macOS,v.v và rất dễ để có thể làm như vậy với các hệ điều hành cụ thể. Python không dễ dàng tạo ra các tệp thực thi nhị phân cho các hệ điều hành như vậy.
|
||||
|
||||
Go là một ngôn ngữ có hiệu năng cao, nó có khả năng biên dịch, thời gian chạy nhanh và sử dụng ít tài nguyên hơn đặc biệt so với Python. Nhiều tối ưu hóa đã được viết bằng Go mang lại hiệu suất rất cao (nguồn bên dưới)
|
||||
|
||||
Không giống như Python thường yêu cầu sử dụng thư viện của bên thứ ba để triển khai một chương trình python cụ thể, Go có một thư viện tiêu chuẩn có hầu hết các chức năng cần thiết cho DevOps được tích hợp sẵn. Nó bao gồm xử lý tệp, dịch vụ web HTTP, xử lý JSON, hỗ trợ cho xử lý đồng thời và song song (concurency, parallelism) cũng như kiểm thử tích hợp (built-in testing).
|
||||
|
||||
Điều này không có nghĩa là chúng ta vứt bỏ Python, tôi chỉ đưa ra những lý do để chọn Go. Nhưng thường thì lý do chính không phải như vậy, chủ yếu là do công ty tôi đang làm việc sử dụng Go để phát triển phần mềm.
|
||||
|
||||
Người ta nói rằng một khi bạn học được ngôn ngữ lập trình đầu tiên, việc tiếp nhận các ngôn ngữ khác trở nên dễ dàng hơn. Có lẽ không có công việc nào trong bất kỳ công ty nào không liên quan đến việc quản lý, architect, quản lý và gỡ lỗi các ứng dụng JavaScript hoặc Node JS.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
|
||||
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
|
||||
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
|
||||
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
|
||||
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
|
||||
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
|
||||
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
|
||||
|
||||
Trong 6 ngày tiếp theo của chủ đề này, tôi dự định sẽ viết lại các ghi chú của tôi cho mỗi ngày với mỗi tài liệu ở trên. Bạn sẽ nhận thấy rằng thường mất khoảng 3 giờ cho mỗi khoá học. Nếu bạn có thời gian, hãy tiếp tục và học nếu thời gian cho phép.
|
||||
|
||||
Hẹn gặp lại các bạn vào [Ngày 8](day08.md).
|
113
vi/Days/day08.md
Normal file
113
vi/Days/day08.md
Normal file
@ -0,0 +1,113 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Thiết lập môi trường DevOps cho Go & Hello World - Ngày 8'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Thiết lập môi trường DevOps cho Go & Hello World
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048857
|
||||
---
|
||||
|
||||
## Thiết lập môi trường DevOps cho Go & Hello World
|
||||
|
||||
Trước khi tìm hiểu một số nguyên tắc cơ bản của Go, chúng ta nên cài đặt Go và làm điều mà mọi tiết học đầu tiên của môn "Lập trình 101" có - ứng dụng Hello World. Để cài đặt Go trên máy trạm của bạn, tôi sẽ cố gắng ghi lại toàn bộ quá trình bằng hình ảnh để mọi người có thể theo dõi.
|
||||
|
||||
Trước hết, hãy truy cập vào [go.dev/dl](https://go.dev/dl/) và chúng ta sẽ có một số tùy chọn có sẵn để tải xuống.
|
||||
|
||||
![](../../Days/Images/Day8_Go1.png)
|
||||
|
||||
|
||||
Nếu bạn đã đi đến ngày hôm này, tôi nghĩ rằng bạn có thể biết hệ điều hành đang chạy trên máy của bạn là hệ điều hành nào.Hãy chọn bản tải xuống thích hợp và sau đó chúng ta có thể bắt đầu cài đặt. **_(Tôi sẽ sử dụng phiên bản mới nhất tại thời điểm viết bài, nhưng khi bạn đọc bài này, các phiên bản mới hơn có thể đã được phát hành)_**
|
||||
|
||||
![](../../Days/Images/Day8_Go2.png)
|
||||
|
||||
Lưu ý rằng nếu bạn đã cài đặt một phiên bản cũ của Go, bạn sẽ phải gỡ bỏ phiên bản đó trước khi cài đặt, việc này được tính hợp trong trình cài đặt của Windows.
|
||||
|
||||
Sau khi hoàn tất, chúng ta sử dụng một dấu nhắc lệnh(command prompt)/terminal để kiểm tra xem chúng ta đã cài đặt Go thành công hay chưa. Nếu bạn không nhận được output như ở bên dưới thì Go chưa được cài đặt và bạn sẽ cần phải kiểm tra lại các bước thực hiện của mình.
|
||||
|
||||
`go version`
|
||||
|
||||
![](../../Days/Images/Day8_Go3.png)
|
||||
|
||||
Tiếp theo, chúng ta sẽ kiểm tra môi trường cho Go để đảm bảo các việc các thư mục làm việc được cấu hình chính xác. Như bạn có thể thấy bên dưới, chúng ta cần đảm bảo rằng những thư mục sau có trên hệ thống của mình.
|
||||
|
||||
![](../../Days/Images/Day8_Go4.png)
|
||||
|
||||
Bạn đã kiểm tra chưa? Bạn có đang theo kịp không? Bạn có thể sẽ nhận được một lỗi giống như dưới đây khi bạn thử và cố gắng điều hướng đến đó.
|
||||
|
||||
![](../../Days/Images/Day8_Go5.png)
|
||||
|
||||
Được rồi, hãy tạo thư mục đó bằng cách sử dụng lệnh mkdir trong PowerShell terminal. Chúng ta cũng cần tạo 3 thư mục trong thư mục Go như bạn sẽ thấy bên dưới.
|
||||
|
||||
![](../../Days/Images/Day8_Go6.png)
|
||||
|
||||
Sau khi chúng ta cài đặt Go và có các thư mục sẵn sàng cho Go hoạt động, chúng ta cần một môi trường phát triển tích hợp (IDE). Có rất nhiều lựa chọn mà bạn có thể sử dụng nhưng phổ biến nhất và IDE mà tôi sử dụng là Visual Studio Code hoặc Code. Bạn có thể tìm hiểu thêm về các IDEs tại [đây](https://www.youtube.com/watch?v=vUn5akOlFXQ).
|
||||
|
||||
Nếu bạn chưa tải xuống và cài đặt VSCode trên máy trạm của mình thì bạn có thể thực hiện việc này bằng cách vào [đây](https://code.visualstudio.com/download). Như bạn có thể thấy bên dưới, bạn có các lựa chọn cho các hệ điều hành khác nhau.
|
||||
|
||||
![](../../Days/Images/Day8_Go7.png)
|
||||
|
||||
Tương tự như với việc cài đặt Go, chúng ta sẽ tải xuống và cài đặt và giữ nguyên các giá trị mặc định. Sau khi hoàn tất, bạn có thể mở VSCode, chọn Open File và điều hướng đến thư mục Go mà chúng ta đã tạo ở trên.
|
||||
|
||||
![](../../Days/Images/Day8_Go8.png)
|
||||
|
||||
Bạn có thể nhận được một cửa sổ hỏi về việc tin tưởng tác giả của thư mục, hãy đọc nó nếu bạn muốn, nhấn Có và tin tưởng các tác giả (Tôi không chịu trách nhiệm sau này nếu bạn bắt đầu mở những thứ bạn không tin tưởng!)
|
||||
|
||||
Bây giờ bạn sẽ thấy ba thư mục chúng ta cũng đã tạo trước đó và những gì chúng ta muốn làm bây giờ là nhấp chuột phải vào thư mục src và tạo một thư mục mới có tên là `Hello`
|
||||
|
||||
![](../../Days/Images/Day8_Go9.png)
|
||||
|
||||
Cho tới lúc này, mọi thứ khác dễ dàng đúng không? Bây giờ chúng ta sẽ tạo chương trình Go đầu tiên của mình mà không hiểu bất cứ thứ gì trong giai đoạn tiếp theo.
|
||||
|
||||
Tiếp theo, tạo một tệp có tên là `main.go` trong thư mục `Hello`. Ngay sau khi bạn nhấn Enter tại file main.go, bạn sẽ được hỏi xem bạn có muốn cài đặt tiện ích mở rộng (extension) cho Go không cũng như các các packages mới. Bạn cũng có thể kiểm tra xem liệu tệp pkg mà chúng ta đã tạo có một số packages mới trong đó hay không?
|
||||
|
||||
![](../../Days/Images/Day8_Go10.png)
|
||||
|
||||
Bây giờ, hãy bắt đầu ứng dụng Hello World, sao chép mã sau vào tệp main.go mới của bạn và lưu lại.
|
||||
|
||||
```
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
fmt.Println("Hello #90DaysOfDevOps")
|
||||
}
|
||||
```
|
||||
|
||||
Bây giờ có thể chúng ta đang không hiểu tất cả những điều ở trên, nhưng chúng ta sẽ đề cập nhiều hơn về các chức năng, packages và các chủ để khác trong những ngày tiếp theo. Trở lại với terminal của bạn và thư mục Hello, chúng ta hãy kiểm tra liệu ứng dụng có chạy đúng hay không sử dụng lệnh bên dưới.
|
||||
|
||||
```
|
||||
go run main.go
|
||||
```
|
||||
|
||||
![](../../Days/Images/Day8_Go11.png)
|
||||
|
||||
Tuy nhiên, không chỉ dừng lại tại đây, nếu chúng ta muốn chạy chương trình của mình trên các máy Windows khác thì sao? Chúng ta có thể xây dựng một tệp thực thi nhị phân bằng câu lệnh dưới đây
|
||||
|
||||
```
|
||||
go build main.go
|
||||
```
|
||||
|
||||
![](../../Days/Images/Day8_Go12.png)
|
||||
|
||||
Nếu chúng ta chạy tệp đó tại một máy khác, kết quả vẫn sẽ giống như vậy:
|
||||
|
||||
```bash
|
||||
$ ./main.exe
|
||||
Hello #90DaysOfDevOps
|
||||
```
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
|
||||
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
|
||||
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
|
||||
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
|
||||
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
|
||||
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
|
||||
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
|
||||
|
||||
Hẹn gặp lại vào [ngày 9](day09.md).
|
||||
|
||||
![](../../Days/Images/Day8_Go13.png)
|
82
vi/Days/day09.md
Normal file
82
vi/Days/day09.md
Normal file
@ -0,0 +1,82 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Giải thích mã Hello World - Ngày 9'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Giải thích mã Hello World
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1099682
|
||||
---
|
||||
|
||||
## Giải thích mã Hello World
|
||||
|
||||
### Cách Go hoạt động
|
||||
|
||||
Trong [Ngày 8](day08.md), chúng ta đã tiến hành cài đặt Go trên máy trạm của bạn sau đó tạo ứng dụng Go đầu tiên của mình.
|
||||
|
||||
Trong phần này, chúng ta sẽ xem xét sâu hơn về mã và tìm hiểu thêm một số điều về Go.
|
||||
|
||||
### Biên dịch là gì
|
||||
|
||||
Trước khi tìm hiểu về [6 dòng mã của Hello World](Go/hello.go), chúng ta cần hiểu về việc biên dịch.
|
||||
|
||||
Các ngôn ngữ lập trình mà chúng ta thường sử dụng như Python, Java, Go và C++ là các ngôn ngữ bậc cao. Có nghĩa là mã mà con người có thể đọc được, nhưng khi máy tính thực thi một chương trình, chúng cần phải được dịch ra mã máy. Quá trình đó được gọi là biên dịch.
|
||||
|
||||
![](../../Days/Images/Day9_Go1.png)
|
||||
|
||||
Bạn có thể thấy những gì chúng ta đã làm vào [Ngày 8](day08.md) ở trên. Chúng ta đã tạo một tệp main.go đơn giản và sử dụng lệnh `go build main.go` để biên dịch ra một tệp thực thi.
|
||||
|
||||
### Gói (Packages) là gì?
|
||||
|
||||
Gói là một tập hợp các tệp nguồn trong cùng một thư mục và được biên dịch cùng nhau. Nói một cách đơn giản hơn, một gói là một loạt các tệp .go trong cùng một thư mục. Bạn có nhớ thư mục Hello ở Ngày 8 không? Khi bạn viết những chương trình phức tạp hơn bằng Go, bạn có thể thấy có folder1 folder2 và folder3 chứa các tệp .go khác nhau tạo nên chương trình với nhiều gói.
|
||||
|
||||
Chúng ta sử dụng các gói để có thể tái sử dụng lại mã của người khác để không phải viết mọi thứ từ đầu. Ví dụ chúng ta muốn có "máy tính" như một phần của chương trình, bạn có thể tìm thấy gói Go chứa các hàm toán học mà bạn có thể sử dụng, giúp bạn tiết kiệm rất nhiều thời gian và công sức.
|
||||
|
||||
Go khuyến khích bạn tổ chức mã của mình thành các gói để dễ dàng tái sử dụng và duy trì.
|
||||
|
||||
### Hello #90DaysOfDevOps Từng dòng một
|
||||
|
||||
Bây giờ hãy xem qua tệp main.go của chúng ta.
|
||||
|
||||
![](../../Days/Images/Day9_Go2.png)
|
||||
|
||||
Trong dòng đầu tiên, bạn có `package main` có nghĩa là tệp này thuộc về một gói có tên là main. Tất cả các tệp .go cần phải thuộc về một gói, chúng cũng phải có `package gìđó` trong dòng mở đầu.
|
||||
|
||||
Một gói có thể được đặt tên tuỳ ý. Chúng ta bắt buộc phải gọi đây là `main` vì nó là điểm bắt đầu của chương trình sẽ có trong gói này, đây là một quy tắc. (Tôi cần hiểu thêm về quy tắc này?)
|
||||
|
||||
![](../../Days/Images/Day9_Go3.png)
|
||||
|
||||
Bất cứ khi nào chúng ta muốn biên dịch và thực thi mã của mình, chúng ta phải cho máy biết nơi thực thi được bắt đầu. Chúng ta thực hiện điều này bằng cách viết một hàm có tên là main. Máy sẽ tìm kiếm một hàm có tên là main để bắt đầu chương trình.
|
||||
|
||||
Hàm là một khối mã có thể thực hiện một số tác vụ cụ thể và có thể được sử dụng trong toàn bộ chương trình.
|
||||
|
||||
Bạn có thể khai báo một hàm với bất kỳ tên nào bằng cách sử dụng `func` nhưng trong trường hợp này, chúng ta cần đặt tên nó là` main` vì đây là nơi mã bắt đầu.
|
||||
|
||||
![](../../Days/Images/Day9_Go4.png)
|
||||
|
||||
Tiếp theo, chúng ta sẽ xem xét dòng 3, nơi chúng ta import, có nghĩa là bạn muốn đưa một gói khác vào chương trình chính của mình. fmt là một gói tiêu chuẩn do Go cung cấp, gói này chứa hàm `Println()` và vì chúng ta đã import hàm này nên có thể sử dụng tại dòng 6. Có một số gói tiêu chuẩn chúng ta có thể đưa vào chương trình và tái sử dụng chúng trong mã, giúp tránh được những rắc rối khi phải viết lại từ đầu. [Thư viện chuẩn của Go](https://pkg.go.dev/std)
|
||||
|
||||
![](../../Days/Images/Day9_Go5.png)
|
||||
|
||||
Hàm `Println()` mà chúng ta có ở đây là một cách để ghi đầu ra tiêu chuẩn (standard output) tại thiết bị đầu cuối - nơi mà tệp thực thi đã được thực thi thành công. Bạn có thể tự do thay đổi đoạn mã ở giữa ().
|
||||
|
||||
![](../../Days/Images/Day9_Go6.png)
|
||||
|
||||
### TLDR
|
||||
|
||||
- **Dòng 1** = Tệp này sẽ nằm trong gói có tên là `main` và nó cần được gọi là `main` vì đó là điểm bắt đầu của chương trình.
|
||||
- **Dòng 3** = Để chúng ta có thể sử dụng hàm `Println()`, cần phải import gói fmt để sử dụng gói này tại dòng 6.
|
||||
- **Dòng 5** = Điểm bắt đầu thực tế, hàm `main`.
|
||||
- **Dòng 6** = Điều này sẽ cho phép chúng ta in "Hello #90DaysOfDevOps" trên hệ thống.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
|
||||
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
|
||||
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
|
||||
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
|
||||
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
|
||||
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
|
||||
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
|
||||
|
||||
Hẹn gặp lại vào [Ngày 10](day10.md).
|
100
vi/Days/day10.md
Normal file
100
vi/Days/day10.md
Normal file
@ -0,0 +1,100 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Không gian làm việc của Go - Ngày 10'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - The Go Workspace
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048701
|
||||
---
|
||||
|
||||
### Không gian làm việc của Go
|
||||
|
||||
Vào [Ngày 8](day08.md), chúng ta đã giới thiệu qua về không gian làm việc của Go, khởi động và demo bằng chương trình `Hello #90DaysOfDevOps`. Tuy nhiên cũng nên tìm hiểu kỹ hơn về không gian làm việc Go.
|
||||
|
||||
Hãy nhớ rằng chúng ta đã chọn các giá trị mặc định khi cài đặt Go và sau đó đã tạo các thư mục Go trong GOPATH mặc định đó nhưng trên thực tế, GOPATH có thể được thay đổi thành bất cứ nơi nào bạn muốn.
|
||||
|
||||
Nếu bạn chạy
|
||||
|
||||
```
|
||||
echo $GOPATH
|
||||
```
|
||||
|
||||
Đầu ra sẽ tương tự như thế này (tên người dùng có thể sẽ khác):
|
||||
|
||||
```
|
||||
/home/michael/projects/go
|
||||
```
|
||||
Sau đó, ở đây, chúng ta đã tạo 3 thư mục. **src**, **pkg** and **bin**
|
||||
|
||||
![](../../Days/Images/Day10_Go1.png)
|
||||
|
||||
**src** là nơi lưu trữ tất cả các chương trình và dự án Go. Điều này xử lý việc quản lý không gian tên của các gói (packages) cho tất cả các kho lưu trữ (repositories) Go. Ở đây bạn có thể thấy rằng máy trạm của tôi có thư mục Hello cho dự án Hello #90DaysOfDevOps.
|
||||
|
||||
![](../../Days/Images/Day10_Go2.png)
|
||||
|
||||
**pkg** là một tệp lưu trữ của các gói đã hoặc đang được cài đặt trong chương trình. Điều này giúp tăng tốc quá trình biên dịch dựa trên việc các gói được sử dụng có thay đổi hay không.
|
||||
|
||||
![](../../Days/Images/Day10_Go3.png)
|
||||
|
||||
**bin** là nơi lưu trữ tất cả các tệp nhị phân đã được biên dịch.
|
||||
|
||||
![](../../Days/Images/Day10_Go4.png)
|
||||
|
||||
Hello #90DaysOfDevOps không phải là một chương trình phức tạp, đây là một ví dụ về chương trình Go phức tạp hơn được lấy từ một tài nguyên tuyệt vời khác [GoChronicles](https://gochronicles.com/)
|
||||
|
||||
![](../../Days/Images/Day10_Go5.png)
|
||||
|
||||
Bạn cũng có thể đi sâu vào một số chi tiết về lý do và cách tổ chức một dự án Go. Nó cũng đi sâu hơn một chút về các thư mục khác mà chúng ta chưa đề cập đến [GoChronicles](https://gochronicles.com/project-structure/)
|
||||
|
||||
### Biên dịch & Chạy mã
|
||||
|
||||
Chúng ta cũng đã giới thiệu sơ qua về việc biên dịch mã ở [ngày 9](day09.md), nhưng hãy đi sâu hơn một chút.
|
||||
|
||||
Cần phải **biên dịch** mã trước khi chạy mã. Có 3 cách để làm vậy với Go
|
||||
|
||||
- go build
|
||||
- go install
|
||||
- go run
|
||||
|
||||
Trước khi đến giai đoạn biên dịch ở trên, chúng ta cần xem xét những gì nhận được sau khi cài đặt Go.
|
||||
|
||||
Khi cài đặt Go vào ngày 8, chúng ta đã cài đặt một thứ được gọi là công cụ Go bao gồm một số chương trình cho phép xây dựng và xử lý các tệp mã nguồn Go của mình. Một trong số những công cụ đó là `go`
|
||||
|
||||
Điều đáng chú ý là bạn có thể cài đặt thêm các công cụ không có trong bản cài đặt Go tiêu chuẩn.
|
||||
|
||||
Nếu bạn mở dấu nhắc lệnh của mình và nhập `go`, bạn sẽ thấy như hình ảnh dưới đây và sau đó bạn sẽ thấy "một số những câu lệnh khác" phía bên dưới, tuy nhiên không chưa cần phải quan tâm tới chúng.
|
||||
|
||||
![](../../Days/Images/Day10_Go6.png)
|
||||
|
||||
Bạn cũng có thể nhớ rằng chúng ta đã sử dụng ít nhất hai công cụ vào ngày 8.
|
||||
|
||||
![](../../Days/Images/Day10_Go7.png)
|
||||
|
||||
Những thứ chúng ta muốn tìm hiểu thêm là build, install and run.
|
||||
|
||||
![](../../Days/Images/Day10_Go8.png)
|
||||
|
||||
- `go run` - Lệnh này biên dịch và chạy gói chính bao gồm các tệp .go được chỉ định trên dòng lệnh. Các file biên dịch được lưu trữ trong một thư mục tạm thời.
|
||||
- `go build` - Để biên dịch các gói và phần phụ thuộc trong thư mục hiện tại. Nếu là gói `main`, sẽ đặt tệp thực thi trong thư mục hiện tại, nếu không, tệp thực thi sẽ được đặt trong thư mục `pkg`. `go build` cũng cho phép bạn tạo một tệp thực thi cho bất kỳ nền tảng, hệ điều hành được hỗ trợ bởi của Go.
|
||||
- `go install` - Tương tự như go build nhưng sẽ đặt tệp thi hành vào thư mục `bin`
|
||||
|
||||
Chúng tôi đã chạy qua go build và go run nhưng vui lòng chạy lại chúng ở đây nếu bạn muốn, `go install` như đã nêu ở trên đặt tệp thực thi vào thư mục bin của chúng tôi.
|
||||
|
||||
Chúng ta đã sử dụng go build và go run nhưng hãy thử lại nếu bạn muốn, `go install` như đã trình bày ở trên, sẽ đặt tệp thực thi trong thư mục `bin`.
|
||||
|
||||
![](../../Days/Images/Day10_Go9.png)
|
||||
|
||||
Hy vọng rằng bạn vừa theo dõi nội dung các ngày qua cùng lúc với xem một trong những video bên dưới. Tôi ghi lại và tóm tắt những thứ này thành ghi chú của bản thân để có thể hiểu được kiến thức nền tảng về Golang. Các tài nguyên dưới đây có thể giúp bạn hiểu rõ hơn về nhiều kiến thức tổng thể khác mà bạn cần khi học Golang, nhưng tôi sẽ chia sẻ một số điều thú vị mà tôi tìm thấy trong hành trình 7 ngày hay 7 giờ của mình.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
|
||||
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
|
||||
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
|
||||
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
|
||||
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
|
||||
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
|
||||
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
|
||||
|
||||
Hẹn gặp lại tại [ngày 11](day11.md).
|
192
vi/Days/day11.md
Normal file
192
vi/Days/day11.md
Normal file
@ -0,0 +1,192 @@
|
||||
---
|
||||
title: "#90DaysOfDevOps - Biến, hằng số & kiểu dữ liệu - Ngày 11"
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Biến và hằng số trong Go
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048862
|
||||
---
|
||||
|
||||
Trước khi đi vào chủ đề ngày hôm nay, tôi muốn gửi lời cảm ơn tới [Techworld with Nana](https://www.youtube.com/watch?v=yyUHQIec83I) với video đi hết những kiến thức cơ bản về Go.
|
||||
|
||||
Vào [ngày 8](day08.md), chúng ta thiết lập môi trường, vào [ngày 9](day09.md), chúng ta đã xem qua mã Hello #90DaysOfDevOps và vào [ngày 10](day10.md)), chúng ta đã tìm hiểu về không gian làm việc Go và đi sâu hơn một chút vào biên dịch và chạy mã.
|
||||
|
||||
Hôm nay chúng ta sẽ tìm hiểu về Biến, Hằng số và Kiểu dữ liệu trong khi viết một chương trình mới.
|
||||
|
||||
## Biến và Hằng số trong Go
|
||||
|
||||
Hãy bắt đầu bằng cách lên kế hoạch cho ứng dụng của chúng ta. Tôi nghĩ một chương trình cho bạn biết số ngày còn lại trong thử thách #90DaysOfDevOps sẽ là một ý tưởng hay.
|
||||
|
||||
Đầu tiên là khi chúng ta xây dựng ứng dụng, nó chào mừng người tham gia và nhận phản hồi từ người dùng về số ngày đã hoàn thành. Chúng ta có thể sử dụng thuật ngữ #90DaysOfDevOps nhiều lần trong suốt chương trình và đây là trường hợp hoàn hảo để #90DaysOfDevOps trở thành một biến trong chương trình.
|
||||
|
||||
- Các biến được sử dụng để lưu trữ các giá trị.
|
||||
- Giống như một hộp nhỏ chứa thông tin hoặc giá trị của chúng ta.
|
||||
- Biến này có thể được sử dụng trong suốt chương trình và cũng có ưu điểm là nếu bạn muốn thay đổi tên thử thách hoặc biến này, bạn chỉ phải thay đổi nó ở một nơi. Nói cách khác, bằng cách thay đổi một giá trị của biến này, nó có thể được chuyển sang các tên các thử thách khác trong cộng đồng.
|
||||
|
||||
Để khai báo điều này trong Go, hãy sử dụng **từ khóa** cho các biến. Khai báo này sẽ được sử dụng trong khối mã `func main` mà chúng ta sẽ nhắc tới sau. Giải thích chi tết về **Từ khoá** tại [đây](https://go.dev/ref/spec#Keywords).
|
||||
|
||||
Hãy nhớ rằng tên biến có tính mô tả. Nếu bạn khai báo một biến, bạn phải sử dụng nó hoặc bạn sẽ gặp lỗi, điều này để tránh có thể có mã chết (mã không bao giờ được sử dụng). Điều này cũng tương tự cho các gói (packages) không được sử dụng.
|
||||
|
||||
```
|
||||
var challenge = "#90DaysOfDevOps"
|
||||
```
|
||||
|
||||
Với khai báo ở trên, bạn có thể thấy chúng ta đã sử dụng một biến khi in ra chuỗi ký tự ở đoạn mã dưới đây.
|
||||
|
||||
```
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
var challenge = "#90DaysOfDevOps"
|
||||
fmt.Println("Welcome to", challenge, "")
|
||||
}
|
||||
```
|
||||
|
||||
Bạn có thể tìm thấy đoạn mã trên tại [day11_example1.go](../../Days/Go/day11_example1.go)
|
||||
|
||||
Sau đó, chúng ta xây dựng mã của với ví dụ trên và nhận được kết quả hiển thị như dưới đây.
|
||||
|
||||
![](../../Days/Images/Day11_Go1.png)
|
||||
|
||||
Chúng ta cũng biết rằng thử thách này kéo dài ít nhất 90 ngày, nhưng với thử thách tiếp theo, nó có thể là 100 ngày, chính vì thế, chúng ta cũng cần một biến ở đây. Tuy nhiên, với chương trình này, chúng ta muốn khai báo nó như một hằng số. Các hằng số cũng giống như các biến, ngoại trừ việc giá trị của chúng không thể thay đổi trong đoạn mã (chúng ta vẫn có thể tạo một ứng dụng mới với mã được giữ nguyên và thay đổi hằng số này nhưng giá trị 90 sẽ không thay đổi khi chúng ta chạy ứng dụng của mình)
|
||||
|
||||
Thêm `const` vào mã và thêm một dòng mã khác để in ra kết quả.
|
||||
|
||||
```
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
var challenge = "#90DaysOfDevOps"
|
||||
const daystotal = 90
|
||||
|
||||
fmt.Println("Welcome to", challenge, "")
|
||||
fmt.Println("This is a", daystotal, "challenge")
|
||||
}
|
||||
```
|
||||
|
||||
Bạn có thể tìm thấy đoạn mã trên tại [day11_example2.go](../../Days/Go/day11_example2.go)
|
||||
|
||||
Nếu chúng ta thực hiện lại câu lệnh `go build` và chạy lại, bạn sẽ thấy kết quả bên dưới.
|
||||
|
||||
![](../../Days/Images/Day11_Go2.png)
|
||||
|
||||
Đây sẽ không phải là phần cuối của chương trình, chúng ta sẽ quay lại vào [ngày 12](day12.md) để thêm các chức năng khác. Bây giờ ta sẽ thêm một biến khác cho số ngày đã hoàn thành trong thử thách.
|
||||
|
||||
Bên dưới, tôi đã thêm biến `dayscomplete` với số ngày đã hoàn thành.
|
||||
|
||||
```
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
var challenge = "#90DaysOfDevOps"
|
||||
const daystotal = 90
|
||||
var dayscomplete = 11
|
||||
|
||||
fmt.Println("Welcome to", challenge, "")
|
||||
fmt.Println("This is a", daystotal, "challenge and you have completed", dayscomplete, "days")
|
||||
fmt.Println("Great work")
|
||||
}
|
||||
```
|
||||
|
||||
Bạn có thể tìm thấy đoạn mã trên tại [day11_example3.go](../../Days/Go/day11_example3.go)
|
||||
|
||||
Hãy chạy lại lệnh `go build` hoặc có thể sử dụng `go run`
|
||||
|
||||
![](../../Days/Images/Day11_Go3.png)
|
||||
|
||||
```
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
var challenge = "#90DaysOfDevOps"
|
||||
const daystotal = 90
|
||||
var dayscomplete = 11
|
||||
|
||||
fmt.Printf("Welcome to %v\n", challenge)
|
||||
fmt.Printf("This is a %v challenge and you have completed %v days\n", daystotal, dayscomplete)
|
||||
fmt.Println("Great work")
|
||||
}
|
||||
```
|
||||
|
||||
Đây là một số ví dụ khác để làm cho mã dễ đọc và chỉnh sửa hơn. Hiện giờ, chúng ta vẫn đang sử dụng hàm `Println` nhưng nó có thể được đơn giản hóa bằng cách sử dụng` Printf` với `%v`, có nghĩa là các biến theo sẽ được xác định ở cuối dòng mã. Chúng ta cũng có thể sử dụng `\n` để xuống dòng.
|
||||
|
||||
Tôi đang sử dụng `%v` vì nó là giá trị mặc định, các tùy chọn khác có ở đây trong [tài liệu của gói fmt](https://pkg.go.dev/fmt), bạn có thể đoạn mã ví dụ tại [day11_example4.go](../../Days/Go/day11_example4.go)
|
||||
|
||||
Các biến cũng có thể được khai bảo một cách đơn giản hơn trong mã của bạn. Thay vì xác định rằng đó là `var` và` type`, bạn có thể viết mã này như sau để có cùng kết quả nhưng đoạn mã sẽ gọn, đẹp và đơn giản hơn. Cách này chỉ áp dụng được với các biến, không sử dụng với hằng số.
|
||||
|
||||
```
|
||||
func main() {
|
||||
challenge := "#90DaysOfDevOps"
|
||||
const daystotal = 90
|
||||
```
|
||||
|
||||
## Kiểu dữ liệu
|
||||
|
||||
Trong các ví dụ trên, chúng ta chưa xác định kiểu dữ liệu của biến, điều này là do chúng ta đã gán cho nó một giá trị và Go đủ thông minh để biết kiểu dữ liệu đó là gì hoặc ít nhất có thể suy ra nó là gì dựa trên giá trị bạn đã gán. Tuy nhiên, nếu chúng ta muốn người dùng nhập dữ liệu, chúng ta phải sử dụng một kiểu dữ liệu cụ thể.
|
||||
|
||||
Cho đến giờ, chúng ta đã sử dụng Chuỗi và Số nguyên trong mã của mình. Số nguyên cho số ngày và chuỗi là tên của thử thách.
|
||||
|
||||
Điều quan trọng cần lưu ý là mỗi kiểu dữ liệu có thể làm những việc khác nhau và hoạt động khác nhau. Ví dụ: số nguyên có thể nhân lên trong khi chuỗi thì không.
|
||||
|
||||
Có bốn loại:
|
||||
|
||||
- **Loại cơ bản - Basic type**: Số, chuỗi và boolean (Numbers, strings, booleans)
|
||||
- **Loại tổng hợp - Aggregate type**: Mảng và cấu trúc (Array, structs)
|
||||
- **Loại tham chiếu -Reference type**: Con trỏ, lát cắt, bản đồ, chức năng và kênh (Pointers, slices, maps, functions, and channels)
|
||||
- **Loại giao diện - Interface type**
|
||||
|
||||
Kiểu dữ liệu là một khái niệm quan trọng trong lập trình. Kiểu dữ liệu chỉ định kích thước và kiểu của các giá trị biến.
|
||||
|
||||
Go được nhập tĩnh, có nghĩa là khi một kiểu dữ liệu của biến được xác định, nó chỉ có thể lưu trữ dữ liệu của kiểu đó.
|
||||
|
||||
Go có ba kiểu dữ liệu cơ bản:
|
||||
|
||||
- **bool**: đại diện cho một giá trị boolean hoặc đúng hoặc sai
|
||||
- **Numeric**: đại diện cho kiểu số nguyên, giá trị dấu phẩy động và kiểu phức tạp
|
||||
- **string**: đại diện cho một giá trị chuỗi
|
||||
|
||||
Tôi thấy đây là nguồn tài liệu rất chi tết về các kiểu dữ liệu [Golang by example](https://golangbyexample.com/all-data-types-in-golang-with-examples/)
|
||||
|
||||
Tôi cũng sẽ đề xuất video [Techworld with Nana](https://www.youtube.com/watch?v=yyUHQIec83I&t=2023s). Tại thời điểm này, video đề cập chi tiết rất nhiều về các loại dữ liệu trong Go.
|
||||
|
||||
Chúng ta có thể làm như sau khi cần khai báo kiểu cho biến của mình:
|
||||
|
||||
```
|
||||
var TwitterHandle string
|
||||
var DaysCompleted uint
|
||||
```
|
||||
|
||||
Bởi vì Go ngụ ý các biến trong đó một giá trị được đưa ra, chúng ta có thể in ra các giá trị đó như sau:
|
||||
|
||||
```
|
||||
fmt.Printf("challenge is %T, daystotal is %T, dayscomplete is %T\n", conference, daystotal, dayscomplete)
|
||||
```
|
||||
|
||||
Có nhiều kiểu số nguyên và kiểu float khác nhau, các liên kết ở trên sẽ trình bày chi tiết về những kiểu này.
|
||||
|
||||
- **int** = số nguyên
|
||||
- **unint** = số nguyên dương
|
||||
- **các loại dấu phẩy động** = các số có chứa thành phần thập phân
|
||||
|
||||
## Resources
|
||||
|
||||
- [StackOverflow 2021 Developer Survey](https://insights.stackoverflow.com/survey/2021)
|
||||
- [Why we are choosing Golang to learn](https://www.youtube.com/watch?v=7pLqIIAqZD4&t=9s)
|
||||
- [Jake Wright - Learn Go in 12 minutes](https://www.youtube.com/watch?v=C8LgvuEBraI&t=312s)
|
||||
- [Techworld with Nana - Golang full course - 3 hours 24 mins](https://www.youtube.com/watch?v=yyUHQIec83I)
|
||||
- [**NOT FREE** Nigel Poulton Pluralsight - Go Fundamentals - 3 hours 26 mins](https://www.pluralsight.com/courses/go-fundamentals)
|
||||
- [FreeCodeCamp - Learn Go Programming - Golang Tutorial for Beginners](https://www.youtube.com/watch?v=YS4e4q9oBaU&t=1025s)
|
||||
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
|
||||
|
||||
Ở phần sau, chúng ta sẽ thêm một số chức năng nhập liệu của người dùng vào chương trình để người dùng có thể trả lời câu hỏi đã hoàn thành bao nhiêu ngày.
|
||||
|
||||
Hẹn gặp lại tại [ngày 12](day12.md).
|
14
vi/README.md
14
vi/README.md
@ -32,13 +32,13 @@ Cách nhanh nhất để liên lạc với tôi là thông qua Twitter tại [@M
|
||||
|
||||
### Học một ngôn ngữ lập trình
|
||||
|
||||
- [✔️] ⌨️ 7 > [The Big Picture: DevOps & Learning a Programming Language](Days/day07.md)
|
||||
- [✔️] ⌨️ 8 > [Setting up your DevOps environment for Go & Hello World](Days/day08.md)
|
||||
- [✔️] ⌨️ 9 > [Let's explain the Hello World code](Days/day09.md)
|
||||
- [✔️] ⌨️ 10 > [The Go Workspace & Compiling & running code](Days/day10.md)
|
||||
- [✔️] ⌨️ 11 > [Variables, Constants & Data Types](Days/day11.md)
|
||||
- [✔️] ⌨️ 12 > [Getting user input with Pointers and a finished program](Days/day12.md)
|
||||
- [✔️] ⌨️ 13 > [Tweet your progress with our new App](Days/day13.md)
|
||||
- [✔️] ⌨️ 7 > [Bức tranh toàn cảnh: DevOps & Học một ngôn ngữ lập trình](Days/day07.md)
|
||||
- [✔️] ⌨️ 8 > [Thiết lập môi trường DevOps cho Go & Hello World](Days/day08.md)
|
||||
- [✔️] ⌨️ 9 > [Giải thích mã Hello World](Days/day09.md)
|
||||
- [✔️] ⌨️ 10 > [Không gian làm việc của Go](Days/day10.md)
|
||||
- [✔️] ⌨️ 11 > [Biến, hằng số & kiểu dữ liệu](Days/day11.md)
|
||||
- [✔️] ⌨️ 12 > [Nhận thông tin đầu vào sử dụng con trỏ và chương trình hoàn thiện](Days/day12.md)
|
||||
- [✔️] ⌨️ 13 > [Tweet tiến trình của bạn với ứng dụng mới của chúng ta](Days/day13.md)
|
||||
|
||||
### Knowing Linux Basics
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user