Merge branch 'MichaelCade:main' into zh_cn
This commit is contained in:
commit
415d1d592b
32
Days/Linux/create-user.sh
Normal file → Executable file
32
Days/Linux/create-user.sh
Normal file → Executable file
@ -1,15 +1,27 @@
|
||||
#! /usr/bin/bash
|
||||
if [ -z "${1}" ]
|
||||
then
|
||||
echo "What is your intended username?"
|
||||
read username
|
||||
echo "What is your password"
|
||||
read password
|
||||
|
||||
echo "What is your intended username?"
|
||||
read username
|
||||
echo "What is your password"
|
||||
read password
|
||||
#A user can be passed in as a command line argument
|
||||
echo "$username user account being created."
|
||||
|
||||
#A user can be passed in as a command line argument
|
||||
echo "$username user account being created."
|
||||
#A user is created with the name of command line argument
|
||||
sudo useradd -m $username
|
||||
|
||||
#A user is created with the name of command line argument
|
||||
sudo useradd -m $username
|
||||
#A password can be parsed in as a command line argument.
|
||||
sudo chpasswd <<< $username:$password
|
||||
|
||||
sleep 2
|
||||
echo "If you want to delete the user then pass 'del' and username in command line argument. e.g: ./create-user.sh del username"
|
||||
|
||||
else
|
||||
sudo userdel -rf "${2}"
|
||||
sleep 2
|
||||
echo "${2} user account successfully deleted."
|
||||
exit 0
|
||||
fi
|
||||
|
||||
#A password can be parsed in as a command line argument.
|
||||
sudo chpasswd <<< $username:$password
|
@ -12,7 +12,7 @@ date: '2022-04-17T10:12:40Z'
|
||||
|
||||
Day 1 of our 90 days and adventure to learn a good foundational understanding of DevOps and tools that help with a DevOps mindset.
|
||||
|
||||
This learning journey started for me a few years back but my focus then was around virtualisation platforms and cloud based technologies, I was looking mostly into Infrastructure as Code and Application configuration management with Terraform and Chef.
|
||||
This learning journey started for me a few years back, but my focus then was around virtualisation platforms and cloud-based technologies, I was looking mostly into Infrastructure as Code and Application configuration management with Terraform and Chef.
|
||||
|
||||
Fast forward to March 2021, I was given an amazing opportunity to concentrate my efforts around the Cloud Native strategy at Kasten by Veeam. Which was going to be a massive focus on Kubernetes and DevOps and the community surrounding these technologies. I started my learning journey and quickly realised there was a very wide world aside from just learning the fundamentals of Kubernetes and Containerisation and it was then when I started speaking to the community and learning more and more about the DevOps culture, tooling and processes so I started documenting some of the areas I wanted to learn in public.
|
||||
|
||||
@ -20,31 +20,31 @@ Fast forward to March 2021, I was given an amazing opportunity to concentrate my
|
||||
|
||||
## Let the journey begin
|
||||
|
||||
If you read the above blog, you will see this is a high level contents for my learning journey and I will say at this point I am no where near an expert in any of these sections but what I wanted to do was share some resources both FREE and some paid for but an option for both as we all have different circumstances.
|
||||
If you read the above blog, you will see this is a high-level contents for my learning journey and I will say at this point I am nowhere near an expert in any of these sections but what I wanted to do was share some resources both FREE and some paid for but an option for both as we all have different circumstances.
|
||||
|
||||
Over the next 90 days I want to document these resources and cover those foundational areas. I would love for the community to also get involved. Share your journey and resources so we can learn in public and help each other.
|
||||
Over the next 90 days, I want to document these resources and cover those foundational areas. I would love for the community to also get involved. Share your journey and resources so we can learn in public and help each other.
|
||||
|
||||
You will see from the opening readme in the project repository that I have split things into sections and it is basically 12 weeks plus 6 days. The first 6 days we will explore the fundamentals of DevOps in general before diving into some of the specific areas. By no way is this list exhaustive and again,I would love for the community to assist in making this a useful resource.
|
||||
You will see from the opening readme in the project repository that I have split things into sections and it is 12 weeks plus 6 days. For the first 6 days, we will explore the fundamentals of DevOps in general before diving into some of the specific areas. By no way is this list exhaustive and again, I would love for the community to assist in making this a useful resource.
|
||||
|
||||
Another resource I will share at this point and that I think everyone should have a good look at, maybe create your own mind map for yourself and your interest and position, is the following:
|
||||
Another resource I will share at this point and that I think everyone should have a good look at, maybe create your mind map for yourself and your interest and position, is the following:
|
||||
|
||||
[DevOps Roadmap](https://roadmap.sh/devops)
|
||||
|
||||
I found this a great resource when I was creating my initial list and blog post on this topic. You can also see there are other areas that go into a lot more detail outside of the 12 topics I have listed here in this repository.
|
||||
I found this a great resource when I was creating my initial list and blog post on this topic. You can also see other areas go into a lot more detail outside of the 12 topics I have listed here in this repository.
|
||||
|
||||
## First Steps - What is DevOps?
|
||||
|
||||
There are so many blog articles and YouTube videos to list here, but as we start the 90 day challenge and we focus on spending around an hour a day learning something new or about DevOps, I thought it was good to get some of the high level of "what DevOps is" down to begin.
|
||||
There are so many blog articles and YouTube videos to list here, but as we start the 90-day challenge and we focus on spending around an hour a day learning something new or about DevOps, I thought it was good to get some of the high level of "what DevOps is" down to begin.
|
||||
|
||||
Firstly, DevOps is not a tool. You cannot buy it, it is not a software sku or an open source GitHub repository you can download. It is also not a programming language, it is also not some dark art magic either.
|
||||
Firstly, DevOps is not a tool. You cannot buy it, it is not a software SKU or an open source GitHub repository you can download. It is also not a programming language, it is also not some dark art magic either.
|
||||
|
||||
DevOps is a way to do smarter things in Software Development. - Hold up... But if you are not a software developer should you turn away right now and not dive into this project??? No. Not at all. Stay... Because DevOps brings together a combination of software development and operations. I mentioned earlier that I was more on the VM side and that would generally fall under the Operations side of the house, but within the community there are people with all different backgrounds where DevOps is 100% going to benefit the individual, Developers, Operations and QA Engineers all can equally learn these best practices by having a better understanding of DevOps.
|
||||
DevOps is a way to do smarter things in Software Development. - Hold up... But if you are not a software developer should you turn away right now and not dive into this project??? No. Not at all. Stay... Because DevOps brings together a combination of software development and operations. I mentioned earlier that I was more on the VM side and that would generally fall under the Operations side of the house, but within the community, there are people with all different backgrounds where DevOps is 100% going to benefit the individual, Developers, Operations and QA Engineers all can equally learn these best practices by having a better understanding of DevOps.
|
||||
|
||||
DevOps is a set of practices that help to reach the goal of this movement: reducing the time between the ideation phase of a product and its release in production to the end-user or whomever it could be an internal team or customer.
|
||||
|
||||
Another area we will dive into in this first week is around **The Agile Methodology**. DevOps and Agile are widely adopted together to achieve continuous delivery of your **Application**.
|
||||
|
||||
The high level take away is that a DevOps mindset or culture is about shrinking the long, drawn out software release process from potentially years to being able to drop smaller releases more frequently. The other key fundamental point to understand here is the responsibility of a DevOps engineer to break down silos between the teams I previously mentioned: Developers, Operations and QA.
|
||||
The high-level takeaway is that a DevOps mindset or culture is about shrinking the long, drawn out software release process from potentially years to being able to drop smaller releases more frequently. The other key fundamental point to understand here is the responsibility of a DevOps engineer to break down silos between the teams I previously mentioned: Developers, Operations and QA.
|
||||
|
||||
From a DevOps perspective, **Development, Testing and Deployment** all land with the DevOps team.
|
||||
|
||||
|
@ -10,49 +10,49 @@ date: '2022-04-17T21:15:34Z'
|
||||
---
|
||||
## Responsibilities of a DevOps Engineer
|
||||
|
||||
Hopefully you are coming into this off the back of going through the resources and post on [Day1 of #90DaysOfDevOps](day01.md)
|
||||
Hopefully, you are coming into this off the back of going through the resources and posting on [Day1 of #90DaysOfDevOps](day01.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.
|
||||
|
||||
## DevOps is the link between the two
|
||||
|
||||
To get to grips with DevOps or the tasks in 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.
|
||||
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.
|
||||
|
||||
Everything starts with the application! You will see so much throughout that it is all about the application when it comes to DevOps.
|
||||
|
||||
Developers will create an application, this can be done with many different technology stacks and lets leave that to the imagination for now as we get into this later. This can also involve many different programming languages, build tools, code repository etc.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
The application will need to be deployed somewhere, lets 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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 all things DNS, DHCP, Load Balancing etc.
|
||||
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.
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
You will also most likely not take over the management of these servers or the application on a daily basis.
|
||||
You will also most likely not take over the management of these servers or the application daily.
|
||||
|
||||
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.
|
||||
|
||||
## High Level Overview
|
||||
## High-Level Overview
|
||||
|
||||
On one side we have our developers creating new features and functionality (as well as bug fixes) for the application.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
The big question is how do we get those features and bug fixes into our production and make it available to those end users?
|
||||
The big question is how do we get those features and bug fixes into our products and make them available to those end users?
|
||||
|
||||
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!
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## Resources
|
||||
|
||||
|
@ -11,24 +11,23 @@ id: 1048825
|
||||
|
||||
As we continue through these next few weeks we are 100% going to come across these titles (Continuous Development, Testing, Deployment, Monitor) over and over again, If you are heading towards the DevOps Engineer role then repeatability will be something you will get used to but constantly enhancing each time is another thing that keeps things interesting.
|
||||
|
||||
In this hour we are going to take a look at the high level view of the application from start to finish and then back round again like a constant loop.
|
||||
In this hour we are going to take a look at the high-level view of the application from start to finish and then back around again like a constant loop.
|
||||
|
||||
### Development
|
||||
Let's take a brand new example of an Application, to start with we have nothing created, maybe as a developer you have to discuss with your client or end user on the requirements and come up with some sort of plan or requirements for your Application. We then need to create from the requirements our brand new application.
|
||||
Let's take a brand new example of an Application, to start with we have nothing created, maybe as a developer, you have to discuss with your client or end user the requirements and come up with some sort of plan or requirements for your Application. We then need to create from the requirements our brand new application.
|
||||
|
||||
In regards to tooling at this stage there is no real requirement here other than choosing your IDE and the programming language you wish to use to write your application.
|
||||
In regards to tooling at this stage, there is no real requirement here other than choosing your IDE and the programming language you wish to use to write your application.
|
||||
|
||||
As a DevOps engineer, remember you are probably not the one creating this plan or coding the application for the end user, this will be a skilled developer.
|
||||
|
||||
But it also would not hurt for you to be able to read some of the code so that you can make the best infrastructure decisions moving forward for your application.
|
||||
|
||||
We previously mentioned that this application can be written in any language. Importantly this should be maintained using a version control system, this is something we will cover also in detail later on and in particular we will dive into **Git**.
|
||||
|
||||
It is also likely that it will not be one developer working on this project although this could be the case but even so best practices would require a code repository to store and collaborate on the code, this could be private or public and could be hosted or privately deployed generally speaking you would hear the likes of **GitHub or GitLab** being used as a code repository. Again we will cover these as part of our section on **Git** later on.
|
||||
We previously mentioned that this application can be written in any language. Importantly this should be maintained using a version control system, this is something we will cover also in detail later on and in particular, we will dive into **Git**.
|
||||
|
||||
It is also likely that it will not be one developer working on this project although this could be the case even so best practices would require a code repository to store and collaborate on the code, this could be private or public and could be hosted or privately deployed generally speaking you would hear the likes of **GitHub or GitLab** being used as a code repository. Again we will cover these as part of our section on **Git** later on.
|
||||
|
||||
### Testing
|
||||
At this stage we have our requirements and we have our application being developed. But we need to make sure we are testing our code in all the various different environments that we have available to us or specifically maybe to the programming language chosen.
|
||||
At this stage, we have our requirements and we have our application being developed. But we need to make sure we are testing our code in all the different environments that we have available to us or specifically maybe to the programming language chosen.
|
||||
|
||||
This phase enables QA to test for bugs, more frequently we see containers being used for simulating the test environment which overall can improve on cost overheads of physical or cloud infrastructure.
|
||||
|
||||
@ -38,9 +37,9 @@ The ability to automate this testing vs 10s,100s or even 1000s of QA engineers h
|
||||
|
||||
### Integration
|
||||
|
||||
Quite importantly Integration is at the middle of the DevOps lifecycle. It is the practice of in which developers require to commit changes to the source code more frequently. This could be on a daily or weekly basis.
|
||||
Quite importantly Integration is at the middle of the DevOps lifecycle. It is the practice in which developers require to commit changes to the source code more frequently. This could be on a daily or weekly basis.
|
||||
|
||||
With every commit your application can go through the automated testing phases and this allows for early detection of issues or bugs before the next phase.
|
||||
With every commit, your application can go through the automated testing phases and this allows for early detection of issues or bugs before the next phase.
|
||||
|
||||
Now you might at this stage be saying "but we don't create applications, we buy it off the shelf from a software vendor" Don't worry many companies do this and will continue to do this and it will be the software vendor that is concentrating on the above 3 phases but you might want to still adopt the final phase as this will enable for faster and more efficient deployments of your off the shelf deployments.
|
||||
|
||||
@ -49,9 +48,9 @@ I would also suggest just having this above knowledge is very important as you m
|
||||
### Deployment
|
||||
Ok so we have our application built and tested against the requirements of our end user and we now need to go ahead and deploy this application into production for our end users to consume.
|
||||
|
||||
This is the stage where the code is deployed to the production servers, now this is where things get extremely interesting and it is where the rest of our 86 days dives deeper into these areas. Because different applications require different possibly hardware or configurations. This is where **Application Configuration Management** and **Infrastructure as Code** could play a key part in your DevOps lifecycle. It might be that your application is **Containerised** but also available to run on a virtual machine. Which then also leads us onto platforms like **Kubernetes** which would be orchestrating those containers and making sure you have the desired state available to your end users.
|
||||
This is the stage where the code is deployed to the production servers, now this is where things get extremely interesting and it is where the rest of our 86 days dives deeper into these areas. Because different applications require different possibly hardware or configurations. This is where **Application Configuration Management** and **Infrastructure as Code** could play a key part in your DevOps lifecycle. It might be that your application is **Containerised** but also available to run on a virtual machine. This then also leads us onto platforms like **Kubernetes** which would be orchestrating those containers and making sure you have the desired state available to your end users.
|
||||
|
||||
All of these bold topics we will go into more detail over the next few weeks to get a better foundational knowledge of what they are and when to use them.
|
||||
Of these bold topics, we will go into more detail over the next few weeks to get a better foundational knowledge of what they are and when to use them.
|
||||
|
||||
### Monitoring
|
||||
|
||||
@ -61,11 +60,11 @@ But now we need to be sure that our end users are getting the experience they re
|
||||
|
||||
This section is also where we are going to capture that feedback wheel about the features that have been implemented and how the end users would like to make these better for them.
|
||||
|
||||
Reliability is a key factor here as well, at the end of the day we want our Application to be available all the time it is required. This then lends to other **observability, security and data management** areas that should be continuously monitored and feedback can always be used to better enhance, update and release the application continuously.
|
||||
Reliability is a key factor here as well, at the end of the day we want our Application to be available all the time it is required. This then leads to other **observability, security and data management** areas that should be continuously monitored and feedback can always be used to better enhance, update and release the application continuously.
|
||||
|
||||
Some input from the community here specifcally [@_ediri](https://twitter.com/_ediri) mentioned also part of this continous process we should also have the FinOps teams involved. Apps & Data are running and stored somewhere you should be monitoring this continously to make sure if things change from a resources point of view your costs are not causing some major financial pain on your Cloud Bills.
|
||||
Some input from the community here specifically [@_ediri](https://twitter.com/_ediri) mentioned also part of this continuous process we should also have the FinOps teams involved. Apps & Data are running and stored somewhere you should be monitoring this continuously to make sure if things change from a resources point of view your costs are not causing some major financial pain on your Cloud Bills.
|
||||
|
||||
I think it is also a good time to bring up the "DevOps Engineer" mentions above, albeit there are many DevOps Engineer positions in the wild that people hold, this is not really the ideal way of positioning the process of DevOps. What I mean is from speaking to others in the community the title of DevOps Engineer should not be the goal for anyone because really any position should be adopting DevOps processes and the culture explained here. DevOps should be used in many different positions such as Cloud-Native engineer/architect, virtualisation admin, cloud architect/engineer, infrastructure admin. This is to name a few but the reason for using DevOps Engineer above was really to highlight the scope or the process used by any of the above positions and more.
|
||||
I think it is also a good time to bring up the "DevOps Engineer" mentioned above, albeit there are many DevOps Engineer positions in the wild that people hold, this is not the ideal way of positioning the process of DevOps. What I mean is from speaking to others in the community the title of DevOps Engineer should not be the goal for anyone because really any position should be adopting DevOps processes and the culture explained here. DevOps should be used in many different positions such as Cloud-Native engineer/architect, virtualisation admin, cloud architect/engineer, and infrastructure admin. This is to name a few but the reason for using DevOps Engineer above was really to highlight the scope of the process used by any of the above positions and more.
|
||||
|
||||
## Resources
|
||||
|
||||
|
@ -29,11 +29,11 @@ and delivery practices based on cooperation between software developers and oper
|
||||
|
||||
## What is the difference between Agile and DevOps
|
||||
|
||||
The difference is mainly the preoccupations. Agile and DevOps have different preoccupations but they are helping each other. Agile wants short iteration, which is only possible with the automation that DevOps brings. Agile wants the customer to try a specific version and quickly give feedback which is only possible if DevOps make the creation of new environment easy.
|
||||
The difference is mainly the preoccupations. Agile and DevOps have different preoccupations but they are helping each other. Agile wants short iteration, which is only possible with the automation that DevOps brings. Agile wants the customer to try a specific version and quickly give feedback which is only possible if DevOps make the creation of a new environment easily.
|
||||
|
||||
### Different participants
|
||||
|
||||
Agile focuses on optimising communication between end-users and developers while DevOps targets developers and operation team members. We could say that agile is outward-oriented towards customers whereas DevOps is a set of internal practices.
|
||||
Agile focuses on optimising communication between end-users and developers while DevOps targets developers and operation, team members. We could say that agile is outward-oriented toward customers whereas DevOps is a set of internal practices.
|
||||
|
||||
### Team
|
||||
|
||||
@ -41,7 +41,7 @@ Agile usually applies to software developers and project managers. The competenc
|
||||
|
||||
### Applied Frameworks
|
||||
|
||||
Agile has a lot of management frameworks to achieve flexibility and transparency: Scrum > Kanban > Lean > Extreme > Crystal > Dynamic > Feature-Driven. DevOps focuses on the development approach in collaboration but doesn't offer specific methodologies. However, DevOps promote practices like Infrastructure as Code, Architecture as Code, Monitoring, Self Healing, end to end test automation ... But per se this is not a framework, rather practices.
|
||||
Agile has a lot of management frameworks to achieve flexibility and transparency: Scrum > Kanban > Lean > Extreme > Crystal > Dynamic > Feature-Driven. DevOps focuses on the development approach in collaboration but doesn't offer specific methodologies. However, DevOps promote practices like Infrastructure as Code, Architecture as Code, Monitoring, Self Healing, end to end test automation ... But per se this is not a framework, but rather practice.
|
||||
|
||||
### Feedback
|
||||
|
||||
@ -49,7 +49,7 @@ In Agile the main source of feedback is the end-user while in DevOps the feedbac
|
||||
|
||||
### Target areas
|
||||
|
||||
Agile focuses on software development more than on deployment and maintenance. DevOps focuses on software development as well but its values and tools also cover deployment and post-release stages like monitoring, high availability, security and data protection.
|
||||
Agile focuses more on software development than deployment and maintenance. DevOps focuses on software development as well but its values and tools also cover deployment and post-release stages like monitoring, high availability, security and data protection.
|
||||
|
||||
### Documentation
|
||||
|
||||
@ -82,7 +82,7 @@ simultaneously just follow 7 steps:
|
||||
|
||||
1. Unite the development and operation teams.
|
||||
2. Create build and run teams, all development and operational concerns are discussed by the entire DevOps team.
|
||||
3. Change your approach to sprints, and assign priority ratings to offer DevOps tasks that have the same value than development tasks. Encourage development and operations teams to exchange their opinion on other teams workflow and possible issues.
|
||||
3. Change your approach to sprints, and assign priority ratings to offer DevOps tasks that have the same value as development tasks. Encourage development and operations teams to exchange their opinion on other teams' workflow and possible issues.
|
||||
4. Include QA in all development stages.
|
||||
5. Choose the right tools.
|
||||
6. Automate everything you can.
|
||||
|
@ -2,20 +2,20 @@
|
||||
title: '#90DaysOfDevOps - Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor > - Day 5'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor >
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048830
|
||||
---
|
||||
## Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor >
|
||||
|
||||
Today we are going to focus on the individual steps from start to finish and the continous cycle of an Application in a DevOps world.
|
||||
Today we are going to focus on the individual steps from start to finish and the continuous cycle of an Application in a DevOps world.
|
||||
|
||||

|
||||
|
||||
### Plan:
|
||||
|
||||
It all starts with the planning process this is where the development team gets together and figure out what types of features and bug fixes that they're going to roll out in their next sprint. This is an opportunity as a DevOps Engineer for you to get involved with that and learn what kinds of things are going to be coming your way that you need to be involved with and also influence their decisions or their path and kind of help them work with the infrastructure that you've built or steer them towards something that's going to work better for them in case they're not on that path and so one key thing to point out here is the developers or software engineering team is your customer as a DevOps engineer so this is your opportunity to work with your customer before they go down a bad path.
|
||||
It all starts with the planning process this is where the development team gets together and figures out what types of features and bug fixes they're going to roll out in their next sprint. This is an opportunity as a DevOps Engineer for you to get involved with that and learn what kinds of things are going to be coming your way that you need to be involved with and also influence their decisions or their path and kind of help them work with the infrastructure that you've built or steer them towards something that's going to work better for them in case they're not on that path and so one key thing to point out here is the developers or software engineering team is your customer as a DevOps engineer so this is your opportunity to work with your customer before they go down a bad path.
|
||||
|
||||
### Code:
|
||||
|
||||
@ -23,7 +23,7 @@ Now once that planning session's done they're going to go start writing the code
|
||||
|
||||
### Build:
|
||||
|
||||
This is where we'll kick off the first of our automation processes because we're going to take their code and we're going to build it depending on what language they're using it may be transpiling it or compiling it or it might be creating a docker image from that code either way we're going to go through that process using our ci cd pipeline
|
||||
This is where we'll kick off the first of our automation processes because we're going to take their code and we're going to build it depending on what language they're using it may be transpiring it or compiling it or it might be creating a docker image from that code either way we're going to go through that process using our ci cd pipeline
|
||||
|
||||
## Testing:
|
||||
|
||||
@ -35,7 +35,7 @@ Once those tests pass we're going to do the release process and depending again
|
||||
|
||||
## Deploy:
|
||||
|
||||
which is the thing that we do next because deployment is like the end game of this whole thing because deployments when we put the code into production and it's not until we do that that our business actually realizes the value from all the time effort and hard work that you and the software engineering team have put into this product up to this point.
|
||||
which is the thing that we do next because deployment is like the end game of this whole thing because deployments are when we put the code into production and it's not until we do that that our business realizes the value from all the time effort and hard work that you and the software engineering team have put into this product up to this point.
|
||||
|
||||
## Operate:
|
||||
|
||||
@ -44,7 +44,7 @@ Once it's deployed we are going to operate it and operate it may involve somethi
|
||||
## Monitor:
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## Rince & Repeat:
|
||||
|
||||
@ -72,7 +72,7 @@ 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 actually makes things clearer for me.
|
||||
This last bit was a bit of a recap for me on Day 3 but think this makes things clearer for me.
|
||||
|
||||
### Resources:
|
||||
|
||||
|
@ -13,9 +13,9 @@ DevOps to begin with was seen to be out of reach for a lot of us as we didn't ha
|
||||
|
||||
You will see from the second link below in references there are a lot of different industries and verticals using DevOps and having a hugely positive effect on their business objectives.
|
||||
|
||||
Obviously the overarching benefit here is DevOps if done correctly should help your Business improve the speed and quality of software development.
|
||||
The overarching benefit here is DevOps if done correctly should help your Business improve the speed and quality of software development.
|
||||
|
||||
I wanted to take this Day to look at succesful companies that have adopted a DevOps practice and share some resources around this, This will be another great one for the community to also dive in and help here. Have you adopted a DevOps culture in your business? Has it been successful?
|
||||
I wanted to take this Day to look at successful companies that have adopted a DevOps practice and share some resources around this, This will be another great one for the community to also dive in and help here. Have you adopted a DevOps culture in your business? Has it been successful?
|
||||
|
||||
I mentioned Netflix above and will touch on them again as it is a very good model and advanced to what we generally see today even still but will also mention some other big name brands that are succeeding it seems.
|
||||
|
||||
@ -25,30 +25,28 @@ In 2010 Amazon moved their physical server footprint to Amazon Web Services (AWS
|
||||
Amazon adopted in 2011 (According to the resource below) a continued deployment process where their developers could deploy code whenever they want and to whatever servers they needed. This enabled Amazon to achieve deploying new software to production servers on average every 11.6 seconds!
|
||||
|
||||
## Netflix
|
||||
Who doesn't use Netflix? obviously a huge quality streaming service with by all accounts at least personally a great user experience.
|
||||
Who doesn't use Netflix? a huge quality streaming service with by all accounts at least personally a great user experience.
|
||||
|
||||
Why is that user experience so great? Well the ability to deliver a service with no recollected memory for me at least of glitches requires speed, flexibility, and attention to quality.
|
||||
Why is that user experience so great? Well, the ability to deliver a service with no recollected memory for me at least of glitches requires speed, flexibility, and attention to quality.
|
||||
|
||||
NetFlix developers can automatically build pieces of code into deployable web images without relying on IT operations. As the images are updated, they are integrated into Netflix’s infrastructure using a custom-built, web-based platform.
|
||||
|
||||
Continous Monitoring is in place so that if the deployment of the images fails, the new images are rolled back and traffic rerouted to the previous version.
|
||||
Continuous Monitoring is in place so that if the deployment of the images fails, the new images are rolled back and traffic rerouted to the previous version.
|
||||
|
||||
There is a great talk listed below that goes into more about the DOs and DONTs that Netflix live and die by within their teams.
|
||||
There is a great talk listed below that goes into more about the DOs and DONTs that Netflix lives and dies by within their teams.
|
||||
|
||||
## Etsy
|
||||
As with many of us and many companies there was a real struggle around slow and painful deployments. In the same vein we might have also experienced working in companies that have lots of siloes and teams that are not really working well together.
|
||||
As with many of us and many companies, there was a real struggle around slow and painful deployments. In the same vein, we might have also experienced working in companies that have lots of siloes and teams that are not working well together.
|
||||
|
||||
From what I can make out at least from reading about Amazon and Netflix, Etsy might have adopted the letting developers deploy their own code around the end of 2009 which might have been before the other two mentioned. (interesting!)
|
||||
From what I can make out at least from reading about Amazon and Netflix, Etsy might have adopted the letting developers deploy their code around the end of 2009 which might have been before the other two were mentioned. (interesting!)
|
||||
|
||||
An interesting take away I read here was that they realised that when developers feel responsibility for deployment they also would take responsibility for application performance, uptime and other goals.
|
||||
An interesting takeaway I read here was that they realised that when developers feel responsible for deployment they also would take responsibility for application performance, uptime and other goals.
|
||||
|
||||
|
||||
|
||||
A learning culture is a key part to DevOps, even failure can be a success if lessons are learned. (not sure where this quote actually came from but it kind of makes sense!)
|
||||
A learning culture is a key part of DevOps, even failure can be a success if lessons are learned. (not sure where this quote came from but it kind of makes sense!)
|
||||
|
||||
I have added some other stories where DevOps has changed the game within some of these massively successful companies.
|
||||
|
||||
|
||||
## Resources
|
||||
|
||||
- [How Netflix Thinks of DevOps](https://www.youtube.com/watch?v=UTKIT6STSVM)
|
||||
@ -63,7 +61,7 @@ I have added some other stories where DevOps has changed the game within some of
|
||||
|
||||
- DevOps is a combo of Development and Operations that allows a single team to manage the whole application development lifecycle that consists of **Development**, **Testing**, **Deployment**, **Operations**.
|
||||
|
||||
- The main focus and aim of DevOps is to shorten the development lifecycle while delivering features, fixes and functionality frequently in close alignment with business objectives.
|
||||
- The main focus and aim of DevOps are to shorten the development lifecycle while delivering features, fixes and functionality frequently in close alignment with business objectives.
|
||||
|
||||
- DevOps is a software development approach through which software can be delivered and developed reliably and quickly. You may also see this referenced as **Continuous Development, Testing, Deployment, Monitoring**
|
||||
|
||||
|
@ -11,7 +11,7 @@ id: 1048856
|
||||
|
||||
I think it is fair to say to be successful in the long term as a DevOps engineer you've got to know at least one programming language at a foundational level. I want to take this first session of this section to explore why this is such a critical skill to have, and hopefully, by the end of this week or section, you are going to have a better understanding of the why, how and what to do to progress with your learning journey.
|
||||
|
||||
I think if I was to ask out on social do you need to have programming skills for DevOps related roles, the answer will be most likely a hard yes? Let me know if you think otherwise? Ok but then a bigger question and this is where you won't get such a clear answer is which programming language? The most common answer I have seen here has been Python or increasingly more often, we're seeing Golang or Go should be the language that you learn.
|
||||
I think if I was to ask out on social do you need to have programming skills for DevOps related roles, the answer will be most likely a hard yes? Let me know if you think otherwise? Ok but then a bigger question and this is where you won't get such a clear answer which programming language? The most common answer I have seen here has been Python or increasingly more often, we're seeing Golang or Go should be the language that you learn.
|
||||
|
||||
To be successful in DevOps you have to have a good knowledge of programming skills is my takeaway from that at least. But we have to understand why we need it to choose the right path.
|
||||
|
||||
@ -42,7 +42,7 @@ An advantage of using a language like Python that is interpreted in a DevOps rol
|
||||
|
||||
## Go vs Python for DevOps
|
||||
|
||||
Go Programs are statically linked, this means that when you compile a go program everything is included in a single binary executable, no external dependencies will be required that would need to be installed on the remote machine, this makes the deployment of go programs easy, compared to python program that uses external libraries you have to make sure that all those libraries are installed on the remote machine that you wish to run on.
|
||||
Go Programs are statically linked, this means that when you compile a go program everything is included in a single binary executable, and no external dependencies will be required that would need to be installed on the remote machine, this makes the deployment of go programs easy, compared to python program that uses external libraries you have to make sure that all those libraries are installed on the remote machine that you wish to run on.
|
||||
|
||||
Go is a platform-independent language, which means you can produce binary executables for *all the operating systems, Linux, Windows, macOS etc and very easy to do so. With Python, it is not as easy to create these binary executables for particular operating systems.
|
||||
|
||||
@ -52,7 +52,7 @@ Unlike Python which often requires the use of third party libraries to implement
|
||||
|
||||
This is by no way throwing Python under the bus I am just giving my reasons for choosing Go but they are not the above Go vs Python it's generally because it makes sense as the company I work for develops software in Go so that is why.
|
||||
|
||||
I will say that once you have or at least I am told as I am not many pages into this chapter right now, is that once you learn your first programming language it becomes easier to take on other languages. You're probably never going to have a single job in any company anywhere where you don't have to deal with manage, architect, orchestrating, debug JavaScript and Node JS applications.
|
||||
I will say that once you have or at least I am told as I am not many pages into this chapter right now, is that once you learn your first programming language it becomes easier to take on other languages. You're probably never going to have a single job in any company anywhere where you don't have to deal with managing, architect, orchestrating, debug JavaScript and Node JS applications.
|
||||
|
||||
## Resources
|
||||
|
||||
@ -64,6 +64,6 @@ I will say that once you have or at least I am told as I am not many pages into
|
||||
- [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)
|
||||
|
||||
Now for the next 6 days of this topic my intention is to work through some of the resources listed above and document my notes for each day. You will notice that they are generally around 3 hours as a full course, I wanted to share my complete list so that if you have time you should move ahead and work through each one if time permits, I will be sticking to my learning hour each day.
|
||||
Now for the next 6 days of this topic, I intend to work through some of the resources listed above and document my notes for each day. You will notice that they are generally around 3 hours as a full course, I wanted to share my complete list so that if you have time you should move ahead and work through each one if time permits, I will be sticking to my learning hour each day.
|
||||
|
||||
See you on [Day 8](day08.md).
|
||||
|
@ -21,7 +21,7 @@ If we made it this far you probably know which workstation operating system you
|
||||
|
||||
Also note if you do have an older version of Go installed you will have to remove this before installing, Windows has this built into the installer and will remove and install as one.
|
||||
|
||||
Once finished you should now open a command prompt/terminal and we want to check that we have Go installed. If you do not get the output that we see below then Go is not installed and you will need to retrace your steps.
|
||||
Once finished you should now open a command prompt/terminal and we want to check that we have to Go installed. If you do not get the output that we see below then Go is not installed and you will need to retrace your steps.
|
||||
|
||||
`go version`
|
||||
|
||||
@ -35,17 +35,17 @@ Did you check? Are you following along? You will probably get something like the
|
||||
|
||||

|
||||
|
||||
Ok, let's create that directory for ease I am going to use the mkdir command in my powershell terminal. We also need to create 3 folders within the Go folder as you will see also below.
|
||||
Ok, let's create that directory for ease I am going to use the mkdir command in my PowerShell terminal. We also need to create 3 folders within the Go folder as you will see also below.
|
||||
|
||||

|
||||
|
||||
Now we have Go installed and we have our Go working directory ready for action. We now need an integrated development environment (IDE) Now there are many out there available that you can use but the most common and the one I use is Visual Studio Code or Code. You can learn more about IDEs [here](https://www.youtube.com/watch?v=vUn5akOlFXQ).
|
||||
Now we have to Go installed and we have our Go working directory ready for action. We now need an integrated development environment (IDE) Now there are many out there available that you can use but the most common and the one I use is Visual Studio Code or Code. You can learn more about IDEs [here](https://www.youtube.com/watch?v=vUn5akOlFXQ).
|
||||
|
||||
If you have not downloaded and installed VSCode already on your workstation then you can do so by heading [here](https://code.visualstudio.com/download). As you can see below you have your different OS options.
|
||||
|
||||

|
||||
|
||||
Much the same as with the Go installation we are going to download and install and keep the defaults. Once complete you can open VSCode and you can select Open File and navigate to our Go directory that we created above.
|
||||
Much the same as with the Go installation we are going to download and install and keep the defaults. Once complete you can open VSCode you can select Open File and navigate to our Go directory that we created above.
|
||||
|
||||

|
||||
|
||||
@ -55,13 +55,13 @@ Now you should see the three folders we also created earlier as well and what we
|
||||
|
||||

|
||||
|
||||
Pretty easy stuff I would say up till this point? Now we are going to create our first Go Program with no understanding about anything we put in this next phase.
|
||||
Pretty easy stuff I would say up till this point? Now we are going to create our first Go Program with no understanding of anything we put in this next phase.
|
||||
|
||||
Next create a file called `main.go` in your `Hello` folder. As soon as you hit enter on the main.go you will be asked if you want to install the Go extension and also packages you can also check that empty pkg file that we made a few steps back and notice that we should have some new packages in there now?
|
||||
Next, create a file called `main.go` in your `Hello` folder. As soon as you hit enter on the main.go you will be asked if you want to install the Go extension and also packages you can also check that empty pkg file that we made a few steps back and notice that we should have some new packages in there now?
|
||||
|
||||

|
||||
|
||||
Now let's get this Hello World app going, copy for the following code into your new main.go file and save that.
|
||||
Now let's get this Hello World app going, copy the following code into your new main.go file and save that.
|
||||
|
||||
```
|
||||
package main
|
||||
@ -72,7 +72,7 @@ func main() {
|
||||
fmt.Println("Hello #90DaysOfDevOps")
|
||||
}
|
||||
```
|
||||
Now I appreciate that the above might make no sense at all, but we will cover more about functions, packages and more in later days. For now let's run our app. Back in the terminal and in our Hello folder we can now check that all is working. Using the command below we can check to see if our generic learning program is working.
|
||||
Now I appreciate that the above might make no sense at all, but we will cover more about functions, packages and more in later days. For now, let's run our app. Back in the terminal and in our Hello folder we can now check that all is working. Using the command below we can check to see if our generic learning program is working.
|
||||
|
||||
```
|
||||
go run main.go
|
||||
@ -103,7 +103,6 @@ Hello #90DaysOfDevOps
|
||||
- [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)
|
||||
|
||||
|
||||
See you on [Day 9](day09.md).
|
||||
|
||||

|
||||
|
@ -2,10 +2,10 @@
|
||||
title: '#90DaysOfDevOps - Let''s explain the Hello World code - Day 9'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Let's explain the Hello World code
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048732
|
||||
id: 1099682
|
||||
---
|
||||
## Let's explain the Hello World code
|
||||
|
||||
@ -16,7 +16,7 @@ On [Day 8](day08.md) we walked through getting Go installed on your workstation
|
||||
In this section, we are going to take a deeper look into the code and understand a few more things about the Go language.
|
||||
|
||||
### What is Compiling?
|
||||
Before we get into the [6 lines of the Hello World code](Go/hello.go) we need to have a bit of an understanding about compiling.
|
||||
Before we get into the [6 lines of the Hello World code](Go/hello.go) we need to have a bit of an understanding of compiling.
|
||||
|
||||
Programming languages that we commonly use such as Python, Java, Go and C++ are high-level languages. Meaning they are human-readable but when a machine is trying to execute a program it needs to be in a form that a machine can understand. We have to translate our human-readable code to machine code which is called compiling.
|
||||
|
||||
@ -25,9 +25,9 @@ Programming languages that we commonly use such as Python, Java, Go and C++ are
|
||||
From the above you can see what we did on [Day 8](day08.md) here, we created a simple Hello World main.go and we then used the command `go build main.go` to compile our executable.
|
||||
|
||||
### What are packages?
|
||||
A package is a collection of source files in the same directory that are compiled together. We can simplify this further, a package is a bunch of .go files in the same directory. Remember our Hello folder from Day 8? If and when you get into more complex Go programs you might find that you have folder1 folder2 and folder3 containing different .go files that make up your program with multiple packages.
|
||||
A package is a collection of source files in the same directory that are compiled together. We can simplify this further, a package is a bunch of .go files in the same directory. Remember our Hello folder from Day 8? If and when you get into more complex Go programs you might find that you have folder1 folder2 and folder3 containing different.go files that make up your program with multiple packages.
|
||||
|
||||
We use packages so we can reuse other peoples code, we don't have to write everything from scratch. Maybe we are wanting a calculator as part of our program, you could probably find an existing Go Package that contains the mathematical functions that you could import into your code saving you a lot of time and effort in the long run.
|
||||
We use packages so we can reuse other people's code, we don't have to write everything from scratch. Maybe we are wanting a calculator as part of our program, you could probably find an existing Go Package that contains the mathematical functions that you could import into your code saving you a lot of time and effort in the long run.
|
||||
|
||||
Go encourages you to organise your code in packages so that it is easy to reuse and maintain source code.
|
||||
|
||||
@ -44,17 +44,17 @@ A package can be named whatever you wish. We have to call this `main` as this is
|
||||
|
||||
Whenever we want to compile and execute our code we have to tell the machine where the execution needs to start. We do this by writing a function called main. The machine will look for a function called main to find the entry point of the program.
|
||||
|
||||
A function is a block of code that can do some specific task for and can be used across the program.
|
||||
A function is a block of code that can do some specific task and can be used across the program.
|
||||
|
||||
You can declare a function with any name using `func` but in this case we need to name it `main` as this is where the code starts.
|
||||
You can declare a function with any name using `func` but in this case, we need to name it `main` as this is where the code starts.
|
||||
|
||||

|
||||
|
||||
Next we are going to look at line 3 of our code, the import, this basically means you want to bring in another package to your main program. fmt is a standard package being used here provided by Go, this package contains the `Println()`function and because we have imported this we can use this in line 6. There are a number of standard packages you can include in your program and leverage or reuse them in your code saving you the hassle of having to write from scratch. [Go Standard Library](https://pkg.go.dev/std)
|
||||
Next, we are going to look at line 3 of our code, the import, this means you want to bring in another package to your main program. fmt is a standard package being used here provided by Go, this package contains the `Println()` function and because we have imported this we can use this in line 6. There are several standard packages you can include in your program and leverage or reuse them in your code saving you the hassle of having to write from scratch. [Go Standard Library](https://pkg.go.dev/std)
|
||||
|
||||

|
||||
|
||||
the `Println()` that we have here is a way in which to write to a standard output to the terminal where ever the executuable has been executed succesfully. Feel free to change the message in between the ().
|
||||
the `Println()` that we have here is a way in which to write standard output to the terminal where ever the executable has been executed successfully. Feel free to change the message in between the ().
|
||||
|
||||

|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - The Go Workspace - Day 10'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - The Go Workspace
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048701
|
||||
@ -22,7 +22,7 @@ The output should be similar to mine (with a different username may be) which is
|
||||
```
|
||||
/home/michael/projects/go
|
||||
```
|
||||
Then within here, we created 3 directories. **src**, **pkg** and **bin**
|
||||
Then here, we created 3 directories. **src**, **pkg** and **bin**
|
||||
|
||||

|
||||
|
||||
@ -55,7 +55,7 @@ To run our code we first must **compile** it. There are three ways to do this wi
|
||||
|
||||
Before we get to the above compile stage we need to take a look at what we get with the Go Installation.
|
||||
|
||||
When we installed Go on Day 8 this installed something known as Go tools which consist of several programs that let us build and process our Go source files. One of the tools is `Go`
|
||||
When we installed Go on Day 8 we installed something known as Go tools which consist of several programs that let us build and process our Go source files. One of the tools is `Go`
|
||||
|
||||
It is worth noting that you can install additional tools that are not in the standard Go installation.
|
||||
|
||||
@ -67,7 +67,7 @@ You might also remember that we have already used at least two of these tools so
|
||||
|
||||

|
||||
|
||||
The ones we want to learn more about are build, install and run.
|
||||
The ones we want to learn more about are the build, install and run.
|
||||
|
||||

|
||||
|
||||
|
@ -21,7 +21,7 @@ The first thing to consider here is that as we are building our app and we are w
|
||||
|
||||
- Variables are used to store values.
|
||||
- Like a little box with our saved information or values.
|
||||
- We can then use this variable across the program which also benefits that if this challenge or variable changes then we only have to change this in one place. Meaning we could translate this to other challenges we have in the community by just changing that one variable value.
|
||||
- We can then use this variable across the program which also benefits that if this challenge or variable changes then we only have to change this in one place. This means we could translate this to other challenges we have in the community by just changing that one variable value.
|
||||
|
||||
To declare this in our Go Program we define a value by using a **keyword** for variables. This will live within our `func main` block of code that you will see later. You can find more about [Keywords](https://go.dev/ref/spec#Keywords)here.
|
||||
|
||||
@ -73,7 +73,7 @@ If we then go through that `go build` process again and run you will see below t
|
||||
|
||||
Finally, and this won't be the end of our program we will come back to this in [Day12](day12.md) to add more functionality. We now want to add another variable for the number of days we have completed the challenge.
|
||||
|
||||
Below I added `dayscomplete` variable with the number of days completed.
|
||||
Below I added the `dayscomplete` variable with the number of days completed.
|
||||
|
||||
```
|
||||
package main
|
||||
@ -134,7 +134,7 @@ Go has three basic data types:
|
||||
|
||||
I found this resource super detailed on data types [Golang by example](https://golangbyexample.com/all-data-types-in-golang-with-examples/)
|
||||
|
||||
I would also suggest [Techworld with Nana](https://www.youtube.com/watch?v=yyUHQIec83I&t=2023s) at this point covers in some detail a lot about the data types in Go.
|
||||
I would also suggest [Techworld with Nana](https://www.youtube.com/watch?v=yyUHQIec83I&t=2023s) at this point covers in detail a lot about the data types in Go.
|
||||
|
||||
If we need to define a type in our variable we can do this like so:
|
||||
|
||||
@ -148,7 +148,7 @@ Because Go implies variables where a value is given we can print out those value
|
||||
```
|
||||
fmt.Printf("challenge is %T, daystotal is %T, dayscomplete is %T\n", conference, daystotal, dayscomplete)
|
||||
```
|
||||
There are many different types of integer and float types the links above will cover off these in detail.
|
||||
There are many different types of integer and float types the links above will cover these in detail.
|
||||
|
||||
- **int** = whole numbers
|
||||
- **unint** = positive whole numbers
|
||||
@ -164,6 +164,6 @@ There are many different types of integer and float types the links above will c
|
||||
- [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)
|
||||
|
||||
Next up we are going to start adding some user input functionality to our program so that we are asking how many days have been completed.
|
||||
Next up we are going to start adding some user input functionality to our program so that we are asked how many days have been completed.
|
||||
|
||||
See you on [Day 12](day12.md).
|
||||
|
@ -25,7 +25,7 @@ We are on day 12 and we would need to change that `dayscomplete` every day and c
|
||||
|
||||
Getting user input, we want to get the value of maybe a name and the number of days completed. For us to do this we can use another function from within the `fmt` package.
|
||||
|
||||
Recap on the `fmt` package, different functions for: formatted input and output (I/O)
|
||||
Recap on the `fmt` package, different functions for formatted input and output (I/O)
|
||||
|
||||
- Print Messages
|
||||
- Collect User Input
|
||||
@ -80,4 +80,3 @@ Below is running this code.
|
||||
- [Hitesh Choudhary - Complete playlist](https://www.youtube.com/playlist?list=PLRAV69dS1uWSR89FRQGZ6q9BR2b44Tr9N)
|
||||
|
||||
See you on [Day 13](day13.md).
|
||||
|
||||
|
@ -9,7 +9,7 @@ id: 1048865
|
||||
---
|
||||
## Tweet your progress with our new App
|
||||
|
||||
On the final day of looking into this programming language, we have only just touched the surface here of the language but it is that start that I think we need to get interested and excited and want to dive more into it.
|
||||
On the final day of looking into this programming language, we have only just touched the surface here of the language but it is at that start that I think we need to get interested and excited and want to dive more into it.
|
||||
|
||||
Over the last few days, we have taken a small idea for an application and we have added functionality to it, in this session I want to take advantage of those packages we mentioned and create the functionality for our app to not only give you the update of your progress on screen but also send a tweet with the details of the challenge and your status.
|
||||
|
||||
@ -30,7 +30,7 @@ Give your application a name
|
||||
|
||||

|
||||
|
||||
You will be then given these API tokens, it is important that you save these somewhere secure. (I have since deleted this app) We will need these later with our Go Application.
|
||||
You will be then given these API tokens, you must save these somewhere secure. (I have since deleted this app) We will need these later with our Go Application.
|
||||
|
||||

|
||||
|
||||
@ -50,7 +50,7 @@ Remember the code we are starting within our application as well [day13_example1
|
||||
|
||||
We now need to think about the code to get our output or message to Twitter in the form of a tweet. We are going to be using [go-twitter](https://github.com/dghubble/go-twitter) This is a Go client library for the Twitter API.
|
||||
|
||||
To test this before putting this into our main application, I created a new directory in our `src` folder called go-twitter-bot, issued the `go mod init github.com/michaelcade/go-twitter-bot` on the folder which then created a `go.mod` file and then we can start writing our new main.go and test this out.
|
||||
To test this before putting this into our main application, I created a new directory in our `src` folder called go-twitter-bot, issued the `go mod init github.com/michaelcade/go-Twitter-bot` on the folder which then created a `go.mod` file and then we can start writing our new main.go and test this out.
|
||||
|
||||
We now need those keys, tokens and secrets we gathered from the Twitter developer portal. We are going to set these in our environment variables. This will depend on the OS you are running:
|
||||
|
||||
|
@ -14,65 +14,52 @@ A lot of technologies start on Linux, especially if they are related to software
|
||||
|
||||
As well lots of open source projects, especially DevOps tools, were designed to run on Linux from the start.
|
||||
|
||||
From a DevOps perspective or in fact any operations role perspective you are going to come across Linux I would say mostly. There is a place for WinOps but the majority of the time you are going to be administering and deploying Linux servers.
|
||||
From a DevOps perspective or any operations role perspective, you are going to come across Linux I would say mostly. There is a place for WinOps but the majority of the time you are going to be administering and deploying Linux servers.
|
||||
|
||||
I have been using Linux on a daily basis for a number of years but my go to desktop machine has always been either macOS or Windows. However, when I moved into the Cloud Native role I am in now I took the plunge to make sure that my laptop was fully Linux based and my daily driver, whilst I still needed Windows for work-based applications and a lot of my audio and video gear does not run on Linux I was forcing myself to run a Linux desktop full time to get a better grasp of a lot of the things we are going to touch on over the next 7 days.
|
||||
I have been using Linux daily for several years but my go to desktop machine has always been either macOS or Windows. However, when I moved into the Cloud Native role I am in now I took the plunge to make sure that my laptop was fully Linux based and my daily driver, whilst I still needed Windows for work-based applications and a lot of my audio and video gear does not run on Linux I was forcing myself to run a Linux desktop full time to get a better grasp of a lot of the things we are going to touch on over the next 7 days.
|
||||
|
||||
## Getting Started
|
||||
I am not suggesting you do the same as me by any stretch as there are easier options and less destructive but I will say taking that full-time step forces you to learn faster on how to make things work on Linux.
|
||||
|
||||
For the majority of these 7 days, I am actually going to deploy a Virtual Machine in Virtual Box on my Windows machine. I am also going to deploy a desktop version of a Linux distribution, whereas a lot of the Linux servers you will be administering will likely be servers that come with no GUI and everything is shell-based. However, as I said at the start a lot of the tools that we covered throughout this whole 90 days started out on Linux I would also strongly encourage you to take the dive into running that Linux Desktop for that learning experience as well.
|
||||
I am not suggesting you do the same as me by any stretch as there are easier options and less destructive but I will say taking that full-time step forces you to learn faster how to make things work on Linux.
|
||||
|
||||
For the majority of these 7 days, I am going to deploy a Virtual Machine in Virtual Box on my Windows machine. I am also going to deploy a desktop version of a Linux distribution, whereas a lot of the Linux servers you will be administering will likely be servers that come with no GUI and everything is shell-based. However, as I said at the start a lot of the tools that we covered throughout this whole 90 days started on Linux I would also strongly encourage you to dive into running that Linux Desktop for that learning experience as well.
|
||||
|
||||
|
||||
For the rest of this post, we are going to concentrate on getting a Ubuntu Desktop virtual machine up and running in our Virtual Box environment. Now we could just download [Virtual Box](https://www.virtualbox.org/) and grab the latest [Ubuntu ISO](https://ubuntu.com/download) from the sites linked and go ahead and build out our desktop environment but that wouldn't be very DevOps of us, would it?
|
||||
|
||||
|
||||
|
||||
Another good reason to use most Linux distributions is that they are free and open-source. We are also choosing Ubuntu as it is probably the most widely used distribution deployed not thinking about mobile devices and enterprise RedHat Enterprise servers. I might be wrong there but with CentOS and the history there I bet Ubuntu is high on the list and it's super simple.
|
||||
|
||||
|
||||
|
||||
## Introducing HashiCorp Vagrant
|
||||
|
||||
|
||||
|
||||
Vagrant is a CLI utility that manages the lifecycle of your virtual machines. We can use vagrant to spin up and down virtual machines across many different platforms including vSphere, Hyper-v, Virtual Box and also Docker. It does have other providers but we will stick with that we are using Virtual Box here so we are good to go.
|
||||
|
||||
|
||||
|
||||
The first thing we need to do is get Vagrant installed on our machine, when you go to the downloads page you will see all the operating systems listed for your choice. [HashiCorp Vagrant](https://www.vagrantup.com/downloads) I am using Windows so I grabbed the binary for my system and went ahead and installed this to my system.
|
||||
|
||||
|
||||
|
||||
Next up we also need to get [Virtual Box](https://www.virtualbox.org/wiki/Downloads) installed. Again this can also be installed on many different operating systems again a good reason to choose this and vagrant is that if you are running Windows, macOS, or Linux then we have you covered here.
|
||||
|
||||
Next up we also need to get [Virtual Box](https://www.virtualbox.org/wiki/Downloads) installed. Again this can also be installed on many different operating systems a good reason to choose this and vagrant is that if you are running Windows, macOS, or Linux then we have you covered here.
|
||||
|
||||
|
||||
Both installations are pretty straightforward. If you have issues both have great communities around them also feel free to reach out and I can try to assist also.
|
||||
|
||||
|
||||
|
||||
## Our first VAGRANTFILE
|
||||
|
||||
|
||||
|
||||
The VAGRANTFILE describes the type of machine we want to deploy. It also defines how we want the configuration and provisioning of this machine need to look.
|
||||
|
||||
|
||||
|
||||
When it comes to saving these and organizing your VAGRANTFILEs I tend to put them in their own folders in my workspace. You can see below how this looks on my system. Hopefully following this you will play around with Vagrant and see the ease of spinning up different systems, it is also great for that rabbit hole is known as distro hopping for Linux Desktops.
|
||||
|
||||
When it comes to saving these and organizing your VAGRANTFILEs I tend to put them in their folders in my workspace. You can see below how this looks on my system. Hopefully following this you will play around with Vagrant and see the ease of spinning up different systems, it is also great for that rabbit hole known as distro hopping for Linux Desktops.
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
Let's take a look at that VAGRANTFILE then and see what we are building.
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
Vagrant.configure("2") do |config|
|
||||
@ -85,7 +72,7 @@ Vagrant.configure("2") do |config|
|
||||
|
||||
v.cpus = 4
|
||||
|
||||
v.customize ["modifyvm", :id, "--vram", "128mb"]
|
||||
v.customize ["modifyvm", :id, "--vram", "128"]
|
||||
|
||||
end
|
||||
|
||||
@ -93,14 +80,12 @@ end
|
||||
|
||||
```
|
||||
|
||||
This is a very simple VAGRANTFILE overall we are saying we want a specific "box" a box being possibly either a public image or private build of the system you are looking for. You can find a long list of "boxes" publicly available here in the [public catalog of Vagrant boxes](https://app.vagrantup.com/boxes/search)
|
||||
|
||||
This is a very simple VAGRANTFILE overall we are saying we want a specific "box" a box being possibly either a public image or private build of the system you are looking for. You can find a long list of "boxes" publicly available here in the [public catalogue of Vagrant boxes](https://app.vagrantup.com/boxes/search)
|
||||
|
||||
|
||||
Next line we are saying we want to use a specific provider in this case it is `VirtualBox` and then we want to define our machine's memory to `8GB and our number of CPUs to `4`. My experience also tells me that you may want to also add the following line if you experience display issues. This will set the video memory to what you want, I would ramp this right up to `128MB but depends on your system.
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
v.customize ["modifyvm", :id, "--vram", ""]
|
||||
@ -110,63 +95,50 @@ v.customize ["modifyvm", :id, "--vram", ""]
|
||||
I have also placed a copy of this specific vagrant file in the [Linux Folder](Linux/VAGRANTFILE)
|
||||
|
||||
|
||||
|
||||
## Provisioning our Linux Desktop
|
||||
|
||||
|
||||
|
||||
We are now ready to get our first machine up and running, in your workstations terminal. In my case I am using PowerShell on my Windows machine, navigate to your projects folder and where you will find your VAGRANTFILE. Once there you can type the command `vagrant up` and if everything is correct then you will see something like the below.
|
||||
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
Another thing to add here is that the network will be set to `NAT` on your virtual machine, at this stage we don't really need to know about NAT and I plan to have a whole session talking about in the next section about Networking. But know that it is the easy button when it comes to getting a machine on your home network, it is also the default networking mode on Virtual Box. You can find out more in the [Virtual Box documentation](https://www.virtualbox.org/manual/ch06.html#network_nat)
|
||||
|
||||
Another thing to add here is that the network will be set to `NAT` on your virtual machine, at this stage we don't need to know about NAT and I plan to have a whole session talking about it in the next section about Networking. But know that it is the easy button when it comes to getting a machine on your home network, it is also the default networking mode on Virtual Box. You can find out more in the [Virtual Box documentation](https://www.virtualbox.org/manual/ch06.html#network_nat)
|
||||
|
||||
|
||||
Once `vagrant up` is complete we can now use `vagrant ssh` to jump straight into the terminal of our new VM.
|
||||
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
This is where we will do most of our exploring over the next few days but I also want to dive into some customizations for your developer workstation that I have done and it makes your life much simpler when running this as your daily driver, and of course, are you really in DevOps unless you have a cool nonstandard terminal?
|
||||
|
||||
|
||||
|
||||
But just to confirm in Virtual Box you should see the login prompt when you select your VM.
|
||||
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
Oh and if you made it this far and you have been asking "WHAT IS THE USERNAME & PASSWORD?"
|
||||
|
||||
|
||||
|
||||
- Username = vagrant
|
||||
|
||||
- Password = vagrant
|
||||
|
||||
|
||||
|
||||
Tomorrow we are going to get into some of the commands and what they do, The terminal is going to be the place to make everything happen.
|
||||
|
||||
## Resources
|
||||
|
||||
- [Learn the Linux Fundamentals - Part 1](https://www.youtube.com/watch?v=kPylihJRG70)
|
||||
- [Linux for hackers (don't worry you don't need be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
|
||||
- [Linux for hackers (don't worry you don't need to be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
|
||||
|
||||
There are going to be lots of resources I find as we go through and much like the Go resources I am generally going to be keeping them to FREE content so we can all partake and learn here.
|
||||
|
||||
As I mentioned next up we will take a look at the commands we might be using on a daily whilst in our Linux environments.
|
||||
|
||||
See you on [Day15](day15.md)
|
||||
|
||||
|
@ -2,18 +2,18 @@
|
||||
title: '#90DaysOfDevOps - Linux Commands for DevOps (Actually everyone) - Day 15'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Linux Commands for DevOps (Actually everyone)
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048834
|
||||
---
|
||||
## Linux Commands for DevOps (Actually everyone)
|
||||
|
||||
I mentioned it [yesterday](day14.md) that we are going to be spending a lot of time in the terminal with some commands to get stuff done.
|
||||
I mentioned [yesterday](day14.md) that we are going to be spending a lot of time in the terminal with some commands to get stuff done.
|
||||
|
||||
I also mentioned that with our vagrant provisioned VM we can use `vagrant ssh` and gain access to our box. You will need to be in the same directory as we provisioned it from.
|
||||
|
||||
For SSH you won't need the username and password, you will only need that if you decide to login to the Virtual Box console.
|
||||
For SSH you won't need the username and password, you will only need that if you decide to log in to the Virtual Box console.
|
||||
|
||||
This is where we want to be as per below:
|
||||
|
||||
@ -21,16 +21,16 @@ This is where we want to be as per below:
|
||||
|
||||
## Commands
|
||||
|
||||
Obviously I cannot cover all the commands here, there are pages and pages of documentation that cover these but also if you are ever in your terminal and you just need to understand options to a specific command we have the `man` pages short for manual. We can use this to go through each of the commands we touch on during this post to find out more options for each one. We can run `man man` which will give you the help for manual pages. To escape the man pages you should press `q` for quit.
|
||||
I cannot cover all the commands here, there are pages and pages of documentation that cover these but also if you are ever in your terminal and you just need to understand options to a specific command we have the `man` pages short for manual. We can use this to go through each of the commands we touch on during this post to find out more options for each one. We can run `man man` which will give you the help for manual pages. To escape the man pages you should press `q` for quit.
|
||||
|
||||

|
||||

|
||||
|
||||
`sudo` If you are familar with Windows and the right click `run as administrator` we can think of `sudo` as very much this. When you run a command with this command you will be running it as `root` it will prompt you for the password before running the command.
|
||||
`sudo` If you are familiar with Windows and the right click `run as administrator` we can think of `sudo` as very much this. When you run a command with this command you will be running it as `root` it will prompt you for the password before running the command.
|
||||
|
||||

|
||||
|
||||
For one off jobs like installing applications or services you might need that `sudo command` but what if you have several tasks to deal with and you want to live as `sudo` for a while? This is where you can use `sudo su` again the same as `sudo` once entered you will be prompted for your `root` password. In a test VM like ours this is fine but I would find it very hard for us to be rolling around as `root` for prolonged periods, bad things can happen. To get out of this elevated position you simply type in `exit`
|
||||
For one off jobs like installing applications or services, you might need that `sudo command` but what if you have several tasks to deal with and you want to live as `sudo` for a while? This is where you can use `sudo su` again the same as `sudo` once entered you will be prompted for your `root` password. In a test VM like ours, this is fine but I would find it very hard for us to be rolling around as `root` for prolonged periods, bad things can happen. To get out of this elevated position you simply type in `exit`
|
||||
|
||||

|
||||
|
||||
@ -38,11 +38,11 @@ I find myself using `clear` all the time, the `clear` command does exactly what
|
||||
|
||||

|
||||
|
||||
Let's now look at some commands where we can actually create things within our system and then visualise them in our terminal, first of all we have `mkdir` this will allow us to create a folder in our system. With the following command we can create a folder in our home directory called Day15 `mkdir Day15`
|
||||
Let's now look at some commands where we can actually create things within our system and then visualise them in our terminal, first of all, we have `mkdir` which will allow us to create a folder in our system. With the following command, we can create a folder in our home directory called Day15 `mkdir Day15`
|
||||
|
||||

|
||||
|
||||
With `cd` this allows us to change directory, so for us to move into our newly created directory we can do this with `cd Day15` tab can also be used to autocomplete the directory available. If we want to get back to where we started we can use `cd ..`
|
||||
With `cd` this allows us to change the directory, so for us to move into our newly created directory we can do this with `cd Day15` tab can also be used to autocomplete the directory available. If we want to get back to where we started we can use `cd ..`
|
||||
|
||||

|
||||
|
||||
@ -50,19 +50,19 @@ With `cd` this allows us to change directory, so for us to move into our newly c
|
||||
|
||||

|
||||
|
||||
I am sure we have all done it where we have navigated to the depths of our file system to a directory and not known where we are. `pwd` gives us the print out of the working directory, pwd as much as it looks like password it stands for print working directory.
|
||||
I am sure we have all done it where we have navigated to the depths of our file system to a directory and not known where we are. `pwd` gives us the printout of the working directory, pwd as much as it looks like password it stands for print working directory.
|
||||
|
||||

|
||||
|
||||
We know how to create folders and directories but how do we create files? We can create files using the `touch` command if we were to run `touch Day15` this would create a file. Ignore `mkdir` we are going see this again later.
|
||||
We know how to create folders and directories but how do we create files? We can create files using the `touch` command if we were to run `touch Day15` this would create a file. Ignore `mkdir` we are going to see this again later.
|
||||
|
||||

|
||||
|
||||
`ls` I can put my house on this, you will use this command so many times, this is going to list the all the files and folders in the current directory. Let's see if we can see that file we just created.
|
||||
`ls` I can put my house on this, you will use this command so many times, this is going to list all the files and folders in the current directory. Let's see if we can see that file we just created.
|
||||
|
||||

|
||||
|
||||
How can we find files on our Linux system? `locate` is going to allow us to search our file system. If we use `locate Day15` it will report back that location of the file. Bonus round is that if you know that the file does exist but you get a blank result then run `sudo updatedb` which will index all the files in the file system then run your `locate` again. If you do not have `locate` available to you, you can install it using this command `sudo apt install mlocate`
|
||||
How can we find files on our Linux system? `locate` is going to allow us to search our file system. If we use `locate Day15` it will report back the location of the file. The bonus round is that if you know that the file does exist but you get a blank result then run `sudo updatedb` which will index all the files in the file system then run your `locate` again. If you do not have `locate` available to you, you can install it using this command `sudo apt install mlocate`
|
||||
|
||||

|
||||
|
||||
@ -82,7 +82,7 @@ We have looked at moving files around but what if I just want to copy files from
|
||||
|
||||

|
||||
|
||||
We have created folders and files but we haven't actually put any contents into our folder, we can add contents a few ways but an easy way is `echo` we can also use `echo` to print out a lot of things in our terminal, I personally use echo a lot to print out system variables to know if they are set or not at least. we can use `echo "Hello #90DaysOfDevOps" > Day15` and this will add this to our file. We can also append to our file using `echo "Commands are fun!" >> Day15`
|
||||
We have created folders and files but we haven't put any contents into our folder, we can add contents a few ways but an easy way is `echo` we can also use `echo` to print out a lot of things in our terminal, I use echo a lot to print out system variables to know if they are set or not at least. we can use `echo "Hello #90DaysOfDevOps" > Day15` and this will add this to our file. We can also append to our file using `echo "Commands are fun!" >> Day15`
|
||||
|
||||

|
||||
|
||||
@ -110,7 +110,7 @@ You can easily add to your bash_profile:
|
||||
```
|
||||
echo 'export HISTTIMEFORMAT="%d-%m-%Y %T "' >> ~/.bash_profile
|
||||
```
|
||||
So as useful to allow the history file grow bigger:
|
||||
So as useful to allow the history file to grow bigger:
|
||||
|
||||
```
|
||||
echo 'export HISTSIZE=100000' >> ~/.bash_profile
|
||||
@ -119,7 +119,7 @@ echo 'export HISTFILESIZE=10000000' >> ~/.bash_profile
|
||||
|
||||

|
||||
|
||||
Need to change your password? `passwd` is going allow us to change our password. Note that when you add your password in like this when it is hidden it will not be shown in `history` however if your command has `-p PASSWORD` then this will be visible in your `history`.
|
||||
Need to change your password? `passwd` is going to allow us to change our password. Note that when you add your password like this when it is hidden it will not be shown in `history` however if your command has `-p PASSWORD` then this will be visible in your `history`.
|
||||
|
||||

|
||||
|
||||
@ -131,7 +131,7 @@ Creating a group again requires `sudo` and we can use `sudo groupadd DevOps` the
|
||||
|
||||

|
||||
|
||||
How do we add users to the `sudo` group, this would be a very rare occassion for this to happen but in order to do this it would be `usermod -a -G sudo NewUser`
|
||||
How do we add users to the `sudo` group, this would be a very rare occasion for this to happen but to do this it would be `usermod -a -G sudo NewUser`
|
||||
|
||||
### Permissions
|
||||
|
||||
@ -150,7 +150,7 @@ A full list:
|
||||
|
||||
You will also see `777` or `775` and these represent the same numbers as the list above but each one represents **User - Group - Everyone**
|
||||
|
||||
Let's take a look at our file. `ls -al Day15` you can see the 3 groups mentioned above, user and group has read & write but everyone only has read.
|
||||
Let's take a look at our file. `ls -al Day15` you can see the 3 groups mentioned above, user and group have read & write but everyone only has read.
|
||||
|
||||

|
||||
|
||||
@ -162,11 +162,11 @@ What about changing the owner of the file? We can use `chown` for this operation
|
||||
|
||||

|
||||
|
||||
A command that you will come across is `awk` where this comes in real use is when you have an output that you only need specific data from. like running `who` we get lines with information, but maybe we only need the names. We can run `who | awk '{print $1}'` to get just a list of that first column.
|
||||
A command that you will come across is `awk` which comes in real use when you have an output that you only need specific data from. like running `who` we get lines with information, but maybe we only need the names. We can run `who | awk '{print $1}'` to get just a list of that first column.
|
||||
|
||||

|
||||
|
||||
If you are looking to read streams of data from standard input, then generates and executes command lines; meaning it can take output of a command and passes it as argument of another command. `xargs` is a useful tool for this use case. If for example I want a list of all the Linux user accounts on the system I can run. `cut -d: -f1 < /etc/passwd` and get the long list we see below.
|
||||
If you are looking to read streams of data from standard input, then generate and execute command lines; meaning it can take the output of a command and passes it as an argument of another command. `xargs` is a useful tool for this use case. If for example, I want a list of all the Linux user accounts on the system I can run. `cut -d: -f1 < /etc/passwd` and get the long list we see below.
|
||||
|
||||

|
||||
|
||||
@ -178,31 +178,13 @@ I didn't mention the `cut` command either, this allows us to remove sections fro
|
||||
|
||||

|
||||
|
||||
Also to note if you type a command and you are no longer with happy with it and you want to start again just hit control + c and this will cancel that line and start you fresh.
|
||||
Also to note if you type a command and you are no longer happy with it and you want to start again just hit control + c and this will cancel that line and start you fresh.
|
||||
|
||||
## Resources
|
||||
|
||||
- [Learn the Linux Fundamentals - Part 1](https://www.youtube.com/watch?v=kPylihJRG70)
|
||||
- [Linux for hackers (don't worry you don't need be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
|
||||
- [Linux for hackers (don't worry you don't need to be a hacker!)](https://www.youtube.com/watch?v=VbEx7B_PTOE)
|
||||
|
||||
See you on [Day16](day16.md)
|
||||
|
||||
This is a pretty heavy list already but I can safely say that I have used all of these commands in my day to day, be it from an administering Linux servers or in my Linux Desktop, it is very easy when you are in Windows or macOS to navigate the UI but in Linux Servers they are not there, everything is done through the terminal.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
This is a pretty heavy list already but I can safely say that I have used all of these commands in my day to day, be it from an administering Linux servers or on my Linux Desktop, it is very easy when you are in Windows or macOS to navigate the UI but in Linux Servers, they are not there, everything is done through the terminal.
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - Managing your Linux System, Filesystem & Storage - Day 16'
|
||||
published: false
|
||||
description: '90DaysOfDevOps - Managing your Linux System, Filesystem & Storage'
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048702
|
||||
@ -81,7 +81,7 @@ On Windows, you have C: drive and that is what we consider the root. On Linux we
|
||||
|
||||

|
||||
|
||||
- `/etc` Likely the most important folder on your Linux system, this is where the majority of your configuration files.
|
||||
- `/etc` Likely the most important folder on your Linux system, this is where the majority of your configuration files are.
|
||||
|
||||

|
||||
|
||||
@ -89,7 +89,7 @@ On Windows, you have C: drive and that is what we consider the root. On Linux we
|
||||
|
||||

|
||||
|
||||
- `/lib` - We mentioned that `/bin` is where our binaries and executables live, `/lib` is where you will find the shared libraries for those.
|
||||
- `/lib` - We mentioned that `/bin` is where our binaries and executables live, and `/lib` is where you will find the shared libraries for those.
|
||||
|
||||

|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - Text Editors - nano vs vim - Day 17'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Text Editors - nano vs vim
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048703
|
||||
@ -43,7 +43,7 @@ The first question might be "How do I exit vim?" that is going to be `escape` an
|
||||
|
||||

|
||||
|
||||
You start in `normal` mode, there are other modes `command, normal, visual, insert` , if we want to add the text we will need to switch from `normal` to `insert` we need to press `i` if you have added some text and would like to save these changes then you would hit escape and then `:wq`
|
||||
You start in `normal` mode, there are other modes `command, normal, visual, insert`, if we want to add the text we will need to switch from `normal` to `insert` we need to press `i` if you have added some text and would like to save these changes then you would hit escape and then `:wq`
|
||||
|
||||

|
||||
|
||||
@ -55,7 +55,7 @@ There is some cool fast functionality with vim that allows you to do menial task
|
||||
|
||||

|
||||
|
||||
Now we want to replace that word with 90DaysOfDevOps, we can do this by hitting `esc` and typing `:%s/Day/90DaysOfDevOps`
|
||||
Now we want to replace that word with 90DaysOfDevOps, we can do this by hitting `ESC` and typing `:%s/Day/90DaysOfDevOps`
|
||||
|
||||

|
||||
|
||||
@ -63,7 +63,7 @@ The outcome when you hit enter is that the word day is then replaced with 90Days
|
||||
|
||||

|
||||
|
||||
Copy and Paste was a big eye-opener for me. Copy is not copy it is yank. we can copy using `yy` on our keyboard in normal mode. `p` paste on the same line, `P` paste on a new line.
|
||||
Copy and Paste was a big eye-opener for me. Copy is not copied it is yanked. we can copy using `yy` on our keyboard in normal mode. `p` paste on the same line, `P` paste on a new line.
|
||||
|
||||
You can also delete these lines by choosing the number of lines you wish to delete followed by `dd`
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - SSH & Web Server - Day 18'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - SSH & Web Server
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048733
|
||||
@ -37,13 +37,13 @@ If we use our client to connect with the correct credentials or SSH key then we
|
||||
|
||||
### Adding a bridged network adapter to our system
|
||||
|
||||
In order for us to use this with our current virtual box VM, we need to add a bridged network adapter to our machine.
|
||||
For us to use this with our current virtual box VM, we need to add a bridged network adapter to our machine.
|
||||
|
||||
Power down your virtual machine, right-click on your machine within Virtual Box and select settings. In the new window then select networking.
|
||||
|
||||

|
||||
|
||||
Now power your machine back on and you will now have an IP address on your local machine. You can confirm this with the `ip addr` command.
|
||||
Now power your machine back on and you will now have an IP address on your local machine. You can confirm this with the `IP addr` command.
|
||||
|
||||
### Confirming SSH server is running
|
||||
|
||||
@ -53,13 +53,13 @@ We know SSH is already configured on our machine as we have been using it with v
|
||||
|
||||

|
||||
|
||||
If your system does not have the SSH server then you can install it by issuing this command `sudo apt install openssh-server`
|
||||
If your system does not have the SSH server then you can install it by issuing this command `sudo apt install OpenSSH-server`
|
||||
|
||||
You then want to make sure that our SSH is allowed if the firewall is running. We can do this with `sudo ufw allow ssh` this is not required on our configuration as we automated this with our vagrant provisioning.
|
||||
|
||||
### Remote Access - SSH Password
|
||||
|
||||
Now that we have our SSH Server listening out on port 22 for any incoming connection requests and we have added the bridged networking we could use putty or an SSH client on our local machine to connect into our system using SSH.
|
||||
Now that we have our SSH Server listening out on port 22 for any incoming connection requests and we have added the bridged networking we could use putty or an SSH client on our local machine to connect to our system using SSH.
|
||||
|
||||

|
||||
|
||||
@ -87,9 +87,9 @@ I am not going to get into what `ed25519` is and means here but you can have a s
|
||||
|
||||

|
||||
|
||||
At this point we have our created SSH key stored in `C:\Users\micha/.ssh/`
|
||||
At this point, we have our created SSH key stored in `C:\Users\micha/.ssh/`
|
||||
|
||||
But in order to link this with our Linux VM we need to copy the key. We can do this by using the `ssh-copy-id vagrant@192.168.169.135`
|
||||
But to link this with our Linux VM we need to copy the key. We can do this by using the `ssh-copy-id vagrant@192.168.169.135`
|
||||
|
||||
I used Powershell to create my keys on my Windows client but there is no `ssh-copy-id` available here. There are ways in which you can do this on Windows and a small search online will find you an alternative, but I will just use git bash on my Windows machine to make the copy.
|
||||
|
||||
@ -111,7 +111,7 @@ there is a line in here with `PasswordAuthentication yes` this will be `#` comme
|
||||
|
||||
Not specifically related to what we have just done with SSH above but I wanted to include this as this is again another task that you might find a little daunting but it really should not be.
|
||||
|
||||
We have our Linux playground VM and at this stage, we want to add an apache webserver to our VM so that we can host a simple website from it that serves out to my home network. Note that this web page will not be accessible from the internet, this can be done but it will not be covered here.
|
||||
We have our Linux playground VM and at this stage, we want to add an apache webserver to our VM so that we can host a simple website from it that serves my home network. Note that this web page will not be accessible from the internet, this can be done but it will not be covered here.
|
||||
|
||||
You might also see this referred to as a LAMP stack.
|
||||
|
||||
@ -137,7 +137,7 @@ MySQL is a database in which we will be storing our data for our simple website.
|
||||
### PHP
|
||||
PHP is a server-side scripting language, we will use this to interact with a MySQL database. The final installation is to get PHP and dependencies installed using `sudo apt-get install php libapache2-mod-php php-mysql`
|
||||
|
||||
The first configuration change we want to make it out of the box apache is using index.html and we want it to use index.php instead.
|
||||
The first configuration change we want to make out of the box apache is using index.html and we want it to use index.php instead.
|
||||
|
||||
We are going to use `sudo nano /etc/apache2/mods-enabled/dir.conf` and we are going to move index.php to the first item in the list.
|
||||
|
||||
@ -163,8 +163,7 @@ Now navigate to your Linux VM IP again with the additional 90Days.php on the end
|
||||
|
||||
### WordPress Installation
|
||||
|
||||
I then walked through this tutorial to get WordPress up on our LAMP stack, some commands are shown below if not shown correctly in the walkthrough [How to install wordpress on Ubuntu with LAMP](https://blog.ssdnodes.com/blog/how-to-install-wordpress-on-ubuntu-18-04-with-lamp-tutorial/)
|
||||
|
||||
I then walked through this tutorial to get WordPress up on our LAMP stack, some commands are shown below if not shown correctly in the walkthrough [How to install WordPress on Ubuntu with LAMP](https://blog.ssdnodes.com/blog/how-to-install-wordpress-on-ubuntu-18-04-with-lamp-tutorial/)
|
||||
|
||||
`sudo mysql -u root -p`
|
||||
|
||||
@ -190,7 +189,7 @@ I then walked through this tutorial to get WordPress up on our LAMP stack, some
|
||||
|
||||
`sudo rm latest.tar.gz`
|
||||
|
||||
At this point you are Step 4 in the linked article, you will need to follow the steps to make sure all correct permissions are in place for the WordPress directory.
|
||||
At this point you are in Step 4 in the linked article, you will need to follow the steps to make sure all correct permissions are in place for the WordPress directory.
|
||||
|
||||
Because this is internal only you do not need to "generate security keys" in this step. Move to Step 5 which is changing the Apache configuration to WordPress.
|
||||
|
||||
|
@ -15,7 +15,7 @@ BASH - **B**ourne **A**gain **Sh**ell
|
||||
|
||||
We could almost dedicate a whole section of 7 days to shell scripting much like the programming languages, bash gives us the capability of working alongside other automation tools to get things done.
|
||||
|
||||
I still speak to a lot of people where they have set up some complex shell scripts to make something happen and they rely on this script for some of the most important things in the business, I am not saying we need to understand shell/bash scripting for this purpose, this is not the way. But we should learn shell/bash scripting to work alongside our automation tools and for ad-hoc tasks.
|
||||
I still speak to a lot of people who have set up some complex shell scripts to make something happen and they rely on this script for some of the most important things in the business, I am not saying we need to understand shell/bash scripting for this purpose, this is not the way. But we should learn shell/bash scripting to work alongside our automation tools and for ad-hoc tasks.
|
||||
|
||||
An example of this that we have used in this section could be the VAGRANTFILE we used to create our VM, we could wrap this into a simple bash script that deleted and renewed this every Monday morning so that we have a fresh copy of our Linux VM every week, we could also add all the software stack that we need on said Linux machine and so on all through this one bash script.
|
||||
|
||||
@ -42,7 +42,7 @@ However, you may see other paths listed in already created shell scripts which c
|
||||
- `#!/bin/bash`
|
||||
- `#!/usr/bin/env bash`
|
||||
|
||||
In the next line in our script, I like to add a comment and add the purpose of the script or at least some information about me. You can do this by using the `#` This allows us to comment out particular lines in our code and provide descriptions for what the upcoming commands will be doing. I find the more notes the better for the user experience especially if you are sharing this.
|
||||
In the next line in our script, I like to add a comment and add the purpose of the script or at least some information about me. You can do this by using the `#` This allows us to comment on particular lines in our code and provide descriptions of what the upcoming commands will be doing. I find the more notes the better for the user experience especially if you are sharing this.
|
||||
|
||||
I sometimes use figlet, a program we installed earlier in the Linux section to create some asci art to kick things off in our scripts.
|
||||
|
||||
@ -73,7 +73,7 @@ Now we can run our script again using `./90DaysOfDevOps.sh` after running the sc
|
||||
Pretty basic stuff but you can start to see hopefully how this could be used to call on other tools as part of ways to make your life easier and automate things.
|
||||
|
||||
### Variables, Conditionals
|
||||
A lot of this section is really a repeat to what we covered when we were learning Golang but I think its worth us diving in here again.
|
||||
A lot of this section is a repeat of what we covered when we were learning Golang but I think it's worth us diving in here again.
|
||||
|
||||
- ### Variables
|
||||
|
||||
@ -152,7 +152,7 @@ We might also use bash scripting to determine information about files and folder
|
||||
- `-d file` True if the file is a directory
|
||||
- `-e file` True if the file exists
|
||||
- `-f file` True if the provided string is a file
|
||||
- `g file` True if the group id is set on a file
|
||||
- `-g file` True if the group id is set on a file
|
||||
- `-r file` True if the file is readable
|
||||
- `-s file` True if the file has a non-zero size
|
||||
|
||||
@ -182,14 +182,14 @@ I found this amazing repository on GitHub that has what seems to be an endless a
|
||||
|
||||
**Requirements**:
|
||||
- A user can be passed in as a command line argument.
|
||||
- A user is created with the name of command line argument.
|
||||
- A password can be parsed in as a command line argument.
|
||||
- A user is created with the name of the command line argument.
|
||||
- A password can be parsed as a command line argument.
|
||||
- The password is set for the user
|
||||
- A message of successful account creation is displayed.
|
||||
|
||||
Let's start with creating our shell script with `touch create_user.sh`
|
||||
|
||||
Before we move on lets also make this executable using `chmod +x create_user.sh`
|
||||
Before we move on let's also make this executable using `chmod +x create_user.sh`
|
||||
|
||||
then we can use `nano create_user.sh` to start editing our script for the scenario we have been set.
|
||||
|
||||
@ -216,7 +216,7 @@ Next up we can take that second requirement "A user is created with the name of
|
||||
#A user can be passed in as a command line argument
|
||||
echo "$1 user account being created."
|
||||
|
||||
#A user is created with the name of command line argument
|
||||
#A user is created with the name of the command line argument
|
||||
sudo useradd -m "$1"
|
||||
|
||||
```
|
||||
@ -227,7 +227,7 @@ We can then check this account has been created with the `awk -F: '{ print $1}'
|
||||
|
||||

|
||||
|
||||
Our next requirement is "A password can be parsed in as a command line argument." First of all we are not going to ever do this in production it is more for us to work through a list of requirements in the lab to understand.
|
||||
Our next requirement is "A password can be parsed as a command line argument." First of all, we are not going to ever do this in production it is more for us to work through a list of requirements in the lab to understand.
|
||||
|
||||
```
|
||||
#! /usr/bin/bash
|
||||
@ -235,10 +235,10 @@ Our next requirement is "A password can be parsed in as a command line argument.
|
||||
#A user can be passed in as a command line argument
|
||||
echo "$1 user account being created."
|
||||
|
||||
#A user is created with the name of command line argument
|
||||
#A user is created with the name of the command line argument
|
||||
sudo useradd -m "$1"
|
||||
|
||||
#A password can be parsed in as a command line argument.
|
||||
#A password can be parsed as a command line argument.
|
||||
sudo chpasswd <<< "$1":"$2"
|
||||
```
|
||||
|
||||
@ -248,9 +248,9 @@ You can see from the below image that we executed our script it created our user
|
||||
|
||||

|
||||
|
||||
The final requirement is "A message of successful account creation is displayed." We actually already have this in the top line of our code and we can see on the above screen shot that we have `90DaysOfDevOps user account being created` is shown. This was left from our testing with the `$1` parameter.
|
||||
The final requirement is "A message of successful account creation is displayed." We already have this in the top line of our code and we can see on the above screenshot that we have a `90DaysOfDevOps user account being created` shown. This was left from our testing with the `$1` parameter.
|
||||
|
||||
Now this script can be used to quickly onboard and set up new users on to our Linux systems. But maybe instead of a few of the historic people having to work through this and then having to get other people their new usernames or passwords we could add some user input that we have previously covered earlier on to capture our variables.
|
||||
Now, this script can be used to quickly onboard and set up new users on to our Linux systems. But maybe instead of a few of the historic people having to work through this and then having to get other people their new usernames or passwords we could add some user input that we have previously covered earlier on to capture our variables.
|
||||
|
||||
```
|
||||
#! /usr/bin/bash
|
||||
@ -263,10 +263,10 @@ read password
|
||||
#A user can be passed in as a command line argument
|
||||
echo "$username user account being created."
|
||||
|
||||
#A user is created with the name of command line argument
|
||||
#A user is created with the name of the command line argument
|
||||
sudo useradd -m $username
|
||||
|
||||
#A password can be parsed in as a command line argument.
|
||||
#A password can be parsed as a command line argument.
|
||||
sudo chpasswd <<< $username:$password
|
||||
```
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - Dev workstation setup - All the pretty things - Day 20'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Dev workstation setup - All the pretty things
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048734
|
||||
@ -17,7 +17,7 @@ I have put together a YouTube video walking through the rest as some people migh
|
||||
|
||||
[](https://youtu.be/jeEslAtHfKc)
|
||||
|
||||
Out of the box our system will look something like the below:
|
||||
Out of the box, our system will look something like the below:
|
||||
|
||||

|
||||
|
||||
@ -28,7 +28,7 @@ We can also see our default bash shell below,
|
||||
A lot of this comes down to dotfiles something we will cover in this final Linux session of the series.
|
||||
|
||||
### dotfiles
|
||||
First up I want to dig into dotfiles, I have said in a previous day that Linux is made up of configuration files. These dotfiles are configuration files for your Linux system and applications.
|
||||
First up I want to dig into dotfiles, I have said on a previous day that Linux is made up of configuration files. These dotfiles are configuration files for your Linux system and applications.
|
||||
|
||||
I will also add that dotfiles are not just used to customise and make your desktop look pretty, there are also dotfile changes and configurations that will help you with productivity.
|
||||
|
||||
@ -59,7 +59,7 @@ I selected `1` to the above question and now we have some more options.
|
||||
|
||||

|
||||
|
||||
You can see from this menu you we can make some out of the box edits to make ZSH configured to our needs.
|
||||
You can see from this menu that we can make some out of the box edits to make ZSH configured to our needs.
|
||||
|
||||
If you exit the wizard with a `0` and then use the `ls -al | grep .zshrc` you should see we have a new configuration file.
|
||||
|
||||
@ -83,11 +83,11 @@ Let's get Oh My ZSH installed, we have a few options with `curl` `wget` or `fetc
|
||||
|
||||
`sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"`
|
||||
|
||||
When you have run the above command you should see some output like below.
|
||||
When you have run the above command you should see some output like the below.
|
||||
|
||||

|
||||
|
||||
Now we can move on to start putting a theme in for our experience, there are well over 100 bundled with Oh My ZSH but my go to for all of my applications and everything is the dracula theme.
|
||||
Now we can move on to start putting a theme in for our experience, there are well over 100 bundled with Oh My ZSH but my go-to for all of my applications and everything is the Dracula theme.
|
||||
|
||||
I also want to add that these two plugins are a must when using Oh My ZSH.
|
||||
|
||||
@ -129,23 +129,23 @@ A short list of the programs I install on the machine using `apt`
|
||||
|
||||
### Dracula theme
|
||||
|
||||
This site is the only theme I am using at the moment. Looks clear, clean and everything looks great. [Dracula Theme](https://draculatheme.com/) It also has you covered when you have lots of other programs you use on your machine.
|
||||
This site is the only theme I am using at the moment. Looks clear, and clean and everything looks great. [Dracula Theme](https://draculatheme.com/) It also has you covered when you have lots of other programs you use on your machine.
|
||||
|
||||
From the link above we can search for zsh on the site and you will find at least two options.
|
||||
|
||||
Follow the instructions listed to insall either manually or using git. Then you will need to finally edit your `.zshrc` configuration file as per below.
|
||||
Follow the instructions listed to install either manually or using git. Then you will need to finally edit your `.zshrc` configuration file as per below.
|
||||
|
||||

|
||||
|
||||
You are next going to want the [Gnome Terminal Dracula theme](https://draculatheme.com/gnome-terminal) with all instructions available here as well.
|
||||
|
||||
It would actually take a long time for me to document each and every step so I created a video walkthrough of the process. (**Click on the image below**)
|
||||
It would take a long time for me to document every step so I created a video walkthrough of the process. (**Click on the image below**)
|
||||
|
||||
[](https://youtu.be/jeEslAtHfKc)
|
||||
|
||||
If you made it this far, then we have now finished our Linux section of the #90DaysOfDevOps. Once again I am open for feedback and additions to resources here.
|
||||
If you made it this far, then we have now finished our Linux section of the #90DaysOfDevOps. Once again I am open to feedback and additions to resources here.
|
||||
|
||||
I also thought on this it was easier to show you a lot of the steps through video vs writing them down here, what do you think to this? I do have a goal to work back through these days and where possible creating video walkthroughs to add in and better maybe explain and show some of the things we have covered. What do you think?
|
||||
I also thought on this it was easier to show you a lot of the steps through video vs writing them down here, what do you think about this? I do have a goal to work back through these days and where possible create video walkthroughs to add in and better maybe explain and show some of the things we have covered. What do you think?
|
||||
|
||||
## Resources
|
||||
|
||||
|
@ -9,24 +9,24 @@ id: 1048761
|
||||
---
|
||||
## The Big Picture: DevOps and Networking
|
||||
|
||||
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.
|
||||
Welcome to Day 21! We are going to be getting into Networking over the next 7 days, Networking and DevOps are the overarching themes but we will need to get into some of the networking fundamentals as well.
|
||||
|
||||
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.
|
||||
Ultimately as we have said previously DevOps is about a culture and process change within your organisation this as we have discussed can be Virtual Machines, Containers, or 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.
|
||||
|
||||
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.
|
||||
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 to do that we have to have a good understanding of what we are automating.
|
||||
|
||||
### What is NetDevOps | Network DevOps?
|
||||
|
||||
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.
|
||||
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. You will also have a good understanding of the hardware or software-defined networking options, switches, routers etc.
|
||||
|
||||
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.
|
||||
But if you are not a network engineer then we probably need to get foundational knowledge across the board in some of those areas so that we can understand the end goal of Network 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
If we think of Network DevOps as 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.
|
||||
|
||||
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)
|
||||
A really good viewpoint and outline of this thinking can be found here. [Network DevOps](https://www.thousandeyes.com/learning/techtorials/network-devops)
|
||||
|
||||
## Networking The Basics
|
||||
|
||||
@ -34,7 +34,7 @@ Let's forget the DevOps side of things to begin with here and we now need to loo
|
||||
|
||||
### Network Devices
|
||||
|
||||
**Host** are any devices which sends or recieve traffic.
|
||||
**Host** are any devices which send or receive traffic.
|
||||
|
||||

|
||||
|
||||
@ -55,13 +55,13 @@ A logical group of hosts which require similar connectivity.
|
||||
|
||||

|
||||
|
||||
**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.
|
||||
**Router** facilitates communication between networks. As 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 control point (security, filtering, redirecting) 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.
|
||||
Routers learn which networks they are attached to. These are 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.
|
||||
A router has an IP address in the networks they are attached to. This IP is also going to be each host's way out of their local network also known as a gateway.
|
||||
|
||||
Routers also create the hierarchy in networks I mentioned earlier.
|
||||
|
||||
@ -75,7 +75,7 @@ Routers also create the hierarchy in networks I mentioned earlier.
|
||||
|
||||
**Switching** is the process of moving data within networks.
|
||||
|
||||
- A Switch is a device who's primary purpose is switching.
|
||||
- A Switch is a device whose primary purpose is switching.
|
||||
|
||||
This is very much a foundational overview of devices as we know there are many different Network Devices such as:
|
||||
|
||||
@ -90,7 +90,7 @@ This is very much a foundational overview of devices as we know there are many d
|
||||
|
||||
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.
|
||||
Over the next few days, we are going to get to know a little more about this list.
|
||||
|
||||
- OSI Model
|
||||
- Network Protocols
|
||||
|
@ -9,7 +9,7 @@ id: 1049037
|
||||
---
|
||||
## The OSI Model - The 7 Layers
|
||||
|
||||
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.
|
||||
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 and plug it into the other host.
|
||||
|
||||
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.
|
||||
|
||||
@ -19,34 +19,34 @@ The rules for networking are divided into seven different layers and those layer
|
||||
|
||||
### Introduction to the OSI Model
|
||||
|
||||
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**.
|
||||
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 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**.
|
||||
|
||||

|
||||
|
||||
### 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.
|
||||
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 to transport the data from one host to another.
|
||||
|
||||

|
||||
|
||||
### 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.
|
||||
Layer 2, the data link enables a 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)
|
||||
This is where we see the first mention of switches that we covered on our first day of networking on [Day 21](day21.md)
|
||||
|
||||

|
||||
|
||||
### 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.
|
||||
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 an 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.
|
||||
|
||||

|
||||
|
||||
So why do we need addressing schemes on both Layer 2 and 3? (MAC Addresses vs IP Addresses)
|
||||
So why do we need addressing schemes on both Layers 2 and 3? (MAC Addresses vs IP Addresses)
|
||||
|
||||
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.
|
||||
|
||||
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)
|
||||
The layer 2 MAC address will go from host to switch/router only, it is focused on hops whereas the layer 3 IP addresses will stay with that packet of data until it reaches its end host. (End to End)
|
||||
|
||||
IP Addresses - Layer 3 = End to End Delivery
|
||||
|
||||
@ -55,16 +55,16 @@ MAC Addresses - Layer 2 = Hop to Hop Delivery
|
||||
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.
|
||||
|
||||
### 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.
|
||||
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.
|
||||
|
||||

|
||||
|
||||
### Session, Presentation, Application
|
||||
Distinction between Layers 5,6,7 is or had become somewhat vague.
|
||||
The 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.
|
||||
|
||||
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.
|
||||
Let's now try and explain what's happening when hosts are communicating with 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.
|
||||
|
||||
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.
|
||||
|
||||
@ -72,8 +72,8 @@ Layer 4 is going to add a header to that data which can facilitate the goal of l
|
||||
|
||||
This may also be known as a segment (Data and Port)
|
||||
|
||||
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.
|
||||
This segment is going to be passed down the OSI stack to layer 3, the network layer, and 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 the 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.
|
||||
@ -86,7 +86,7 @@ I did mention above the naming for each layer of header plus data but decided to
|
||||
|
||||

|
||||
|
||||
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.
|
||||
The Application sending the data is being sent somewhere so the receiving is somewhat in reverse to get that back up the stack and into the receiving host.
|
||||
|
||||

|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - Network Protocols - Day 23'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Network Protocols
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048704
|
||||
@ -21,13 +21,13 @@ Connects IP addresses to fixed physical machine addresses, also known as MAC add
|
||||
|
||||
- FTP - File Transfer Protocol
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||

|
||||
|
||||
- SMTP - Simple Mail Transfer Protocol
|
||||
|
||||
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.
|
||||
Used for email transmission, mail servers use SMTP to send and receive mail messages. You will still find even with Microsoft 365 that the SMTP protocol is used for the same purpose.
|
||||
|
||||

|
||||
|
||||
@ -39,19 +39,19 @@ HTTP is the foundation of the internet and browsing content. Giving us the abili
|
||||
|
||||
- SSL - Secure Sockets Layer | TLS - Transport Layer Security
|
||||
|
||||
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 has taken over from SSL, TLS is a [Cryptographic Protocol]() that provides secure communications over a network. It can and will be found in the mail, Instant Messaging and other applications but most commonly it is used to secure HTTPS.
|
||||
|
||||

|
||||
|
||||
- HTTPS - HTTP secured with SSL/TLS
|
||||
|
||||
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.
|
||||
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 authentication, privacy and integrity whilst data is exchanged between hosts.
|
||||
|
||||

|
||||
|
||||
- DNS - Domain Name System
|
||||
|
||||
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.
|
||||
The DNS is used to map human-friendly 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.
|
||||
|
||||
This is where DNS comes in, it ensures that hosts, services and other resources are reachable.
|
||||
|
||||
@ -72,15 +72,15 @@ There are 4 things that we need on every host for it to be able to achieve both
|
||||
|
||||
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.
|
||||
|
||||
Subnet mask we will cover shortly, but you can think of this as post code or zip code.
|
||||
Subnet mask we will cover shortly, but you can think of this as postcode 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.
|
||||
A 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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
Another example is you head into a coffee shop, grab a coffee and sit down with your laptop or your phone let's 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.
|
||||
|
||||

|
||||
|
||||
@ -90,17 +90,17 @@ A subnet is a logical subdivision of an IP network.
|
||||
|
||||
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.
|
||||
Each subnet is a logical subdivision of the bigger network. Connected devices with enough subnet share common IP address identifiers, enabling them to communicate with each other.
|
||||
|
||||
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.
|
||||
An organisation is responsible for determining the 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 subnetworks supporting a few devices.
|
||||
|
||||
Among other advantages, segmenting large
|
||||
networks into subnets enables IP address
|
||||
networks into subnets enable IP address
|
||||
reallocation and relieves network congestion, streamlining, network communication and efficiency.
|
||||
|
||||
Subnets can also improve network security.
|
||||
@ -108,12 +108,9 @@ If a section of a network is compromised, it can be quarantined, making it diffi
|
||||
|
||||

|
||||
|
||||
|
||||
## 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)
|
||||
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - Network Automation - Day 24'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Network Automation
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048805
|
||||
@ -24,9 +24,9 @@ To break this down you would need to identify how the task or process that you'r
|
||||
|
||||
"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.
|
||||
Have a framework or design structure that you're trying to achieve know what your end goal is and then work 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.
|
||||
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, and your infrastructure, so begin to build the concepts and model them around your existing infrastructure, you're existing applications.
|
||||
|
||||
### Approach to Networking Automation
|
||||
|
||||
@ -39,7 +39,7 @@ We should identify the tasks and perform a discovery on network change requests
|
||||
|
||||
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.
|
||||
- The 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)
|
||||
@ -55,7 +55,7 @@ Reusable policies, define and simplify reusable service tasks, processes and inp
|
||||
- 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?
|
||||
Combine the policies with business-specific activities. How does implementing this policy help the business? Saves time? Saves Money? Provides a better business outcome?
|
||||
|
||||
- Ensure that service tasks are interoperable.
|
||||
- Associate the incremental service tasks so that they align to create business services.
|
||||
@ -80,7 +80,7 @@ Orchestrate the network service!
|
||||
|
||||
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.
|
||||
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 platforms 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.
|
||||
|
||||
@ -131,7 +131,7 @@ Analyse APIs - Postman is a great tool for analysing RESTful APIs. Helps to buil
|
||||
|
||||
[Network Test Automation](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.
|
||||
Over the next 3 days, I am planning to get more hands-on with some of the things we have covered and put some work in around Python and Network automation.
|
||||
|
||||
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.
|
||||
|
||||
|
@ -13,9 +13,9 @@ Python is the standard language used for automated network operations.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
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 is 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.
|
||||
|
||||
- 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.
|
||||
- Readability and ease of use - It seems that Python seems just makes sense. There don'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.
|
||||
|
||||
Pycharm might be another IDE worth mentioning here.
|
||||
|
||||
@ -59,7 +59,7 @@ We are going to do everything on EVE-NG with the community edition.
|
||||
|
||||
The community edition comes in ISO and OVF formats for [download](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.
|
||||
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 for a hypervisor.
|
||||
|
||||

|
||||
|
||||
@ -81,11 +81,11 @@ Open VMware Workstation and then select `file` and `open`
|
||||
|
||||

|
||||
|
||||
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.
|
||||
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 this.
|
||||
|
||||

|
||||
|
||||
Navigate to the location that you downloaded the EVE-NG OVF image to and begin the import.
|
||||
Navigate to the location where you downloaded the EVE-NG OVF image and begin the import.
|
||||
|
||||
Give it a recognisable name and store the virtual machine somewhere on your system.
|
||||
|
||||
@ -93,7 +93,7 @@ Give it a recognisable name and store the virtual machine somewhere on your syst
|
||||
|
||||
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)
|
||||
|
||||
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.
|
||||
Also, make sure the Virtualise Intel VT-x/EPT or AMD-V/RVI checkbox is enabled. This option instructs the 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.
|
||||
|
||||

|
||||
|
||||
@ -111,7 +111,7 @@ When you want to go back and use WSL2 then you will need to run this command and
|
||||
|
||||
`bcdedit /set hypervisorlaunchtype auto`
|
||||
|
||||
Both of these commands should be ran as administrator!
|
||||
Both of these commands should be run 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.
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - Building our Lab - Day 26'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Building our Lab
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048762
|
||||
@ -21,7 +21,7 @@ There is also a client pack that allows us to choose which application is used w
|
||||
|
||||
Quick Tip: If you are using Linux as your client then there is this [client pack](https://github.com/SmartFinn/eve-ng-integration).
|
||||
|
||||
The install is a straightforward next,next and I would suggest leaving the defaults.
|
||||
The install is straightforward next, next and I would suggest leaving the defaults.
|
||||
|
||||
### Obtaining network images
|
||||
|
||||
@ -53,7 +53,7 @@ Inside the EVE-NG web interface, we are going to create our new network topology
|
||||
|
||||
#### Adding our Nodes to 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.
|
||||
When you first log in to EVE-NG you will see a screen like the below, we want to start by creating our first lab.
|
||||
|
||||

|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - Getting Hands-On with Python & Network - Day 27'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Getting Hands-On with Python & Network
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048735
|
||||
@ -15,7 +15,7 @@ We will be using an SSH tunnel to connect to our devices from our client vs teln
|
||||
|
||||
## 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.
|
||||
For us to interact with our switches we either need a workstation inside the EVE-NG network or 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.
|
||||
|
||||

|
||||
|
||||
@ -25,13 +25,13 @@ To do this, we have right-clicked on our canvas and we have selected network and
|
||||
|
||||
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?)
|
||||
|
||||
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.
|
||||
I have then logged on to each of our devices and I have run through the following commands for the interfaces applicable to where the cloud comes in.
|
||||
|
||||
```
|
||||
enable
|
||||
config t
|
||||
int gi0/0
|
||||
ip add dhcp
|
||||
IP add DHCP
|
||||
no sh
|
||||
exit
|
||||
exit
|
||||
@ -74,7 +74,7 @@ We can use [netmiko_sendchange.py](Networking/netmiko_sendchange.py) to achieve
|
||||
|
||||

|
||||
|
||||
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)
|
||||
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 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)
|
||||
|
||||

|
||||
|
||||
|
@ -2,14 +2,14 @@
|
||||
title: '#90DaysOfDevOps - The Big Picture: DevOps & The Cloud - Day 28'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - The Big Picture DevOps & The Cloud
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048737
|
||||
---
|
||||
## The Big Picture: DevOps & The Cloud
|
||||
|
||||
When it comes to cloud computing and what is offered, it goes very nicely with the DevOps ethos and processes. We can think of Cloud Computing bringing the technology and services whilst DevOps as we have mentioned many times before is about the process and process improvement.
|
||||
When it comes to cloud computing and what is offered, it goes very nicely with the DevOps ethos and processes. We can think of Cloud Computing as bringing the technology and services whilst DevOps as we have mentioned many times before is about the process and process improvement.
|
||||
|
||||
But to start with that cloud learning journey is a steep one and making sure you know and understand all elements or the best service to choose for the right price point is confusing.
|
||||
|
||||
@ -21,7 +21,7 @@ If we look at what we mean by the Public Cloud at a 40,000ft view, it is about r
|
||||
|
||||

|
||||
|
||||
In this first section, I want to get into and describe a little more of what Public Cloud is and some of the building blocks that get referred to as the Public Cloud overall.
|
||||
In this first section, I want to get into and describe a little more of what a Public Cloud is and some of the building blocks that get referred to as the Public Cloud overall.
|
||||
|
||||
### SaaS
|
||||
|
||||
@ -31,9 +31,9 @@ Oh, and you would also have to make sure you were backing up your data, although
|
||||
|
||||
What SaaS does and in particular Microsoft 365, because I mentioned Exchange is removing that administration overhead and they provide a service that delivers your exchange functionality by way of mail but also much other productivity (Office 365) and storage options (OneDrive) that overall gives a great experience to the end-user.
|
||||
|
||||
Other SaaS applications are widely adopted, such as Salesforce, SAP, Oracle, Google, Apple. All removing that burden of having to manage more of the stack.
|
||||
Other SaaS applications are widely adopted, such as Salesforce, SAP, Oracle, Google, and Apple. All removing that burden of having to manage more of the stack.
|
||||
|
||||
I am sure there is a story with DevOps and SaaS-based applications but I am struggling to find out what they may be. I know Azure DevOps has some great integrations with Microsoft 365 that I might have a look into and report back.
|
||||
I am sure there is a story with DevOps and SaaS-based applications but I am struggling to find out what they may be. I know Azure DevOps has some great integrations with Microsoft 365 that I might have a look into and report back to.
|
||||
|
||||

|
||||
|
||||
@ -48,15 +48,15 @@ Some will also see the public cloud as a much wider offering that includes those
|
||||

|
||||
*thousands more companies could land on this, I am merely picking from local, regional, telco and global brands I have worked with and am aware of.*
|
||||
|
||||
We mentioned in the SaaS section that Cloud removed the responsibility or the burden of having to administer parts of a system. If SaaS we see a lot of the abstraction layers removed i.e the physical systems, network, storage, operating system, even application to some degree. When it comes to the cloud there are various levels of abstraction we can remove or keep depending on your requirements.
|
||||
We mentioned in the SaaS section that Cloud removed the responsibility or the burden of having to administer parts of a system. If SaaS we see a lot of the abstraction layers removed i.e the physical systems, network, storage, operating system, and even application to some degree. When it comes to the cloud there are various levels of abstraction we can remove or keep depending on your requirements.
|
||||
|
||||
We have already mentioned SaaS but there are at least two more to mention regarding the public cloud.
|
||||
|
||||
Infrastructure as a service - You can think of this layer as a virtual machine but whereas on-premises you will be having to look after the physical layer in the cloud this is not the case, the physical is the cloud providers responsibility and you will manage and administer the Operating System, the data and the applications you wish to run.
|
||||
Infrastructure as a service - You can think of this layer as a virtual machine but whereas on-premises you will be having to look after the physical layer in the cloud this is not the case, the physical is the cloud provider's responsibility and you will manage and administer the Operating System, the data and the applications you wish to run.
|
||||
|
||||
Platform as a service - This continues to remove the responsibility of layers and this is really about you taking control of the data and the application but not having to worry about the underpinning hardware or operating system.
|
||||
|
||||
There are many other aaS offerings out there but these are the two fundamentals. You might see offerings around StaaS (Storage as a service) which provides you with your storage layer but without having to worry about the hardware underneath. Or you might have heard CaaS for Containers as a service which we will get onto, later on, another aaS we will look to cover over the next 7 days is FaaS (Functions as a Service) where maybe you do not need a running system up all the time and you just want a function to be executed as and when.
|
||||
There are many other aaS offerings out there but these are the two fundamentals. You might see offerings around StaaS (Storage as a service) which provide you with your storage layer but without having to worry about the hardware underneath. Or you might have heard CaaS for Containers as a service which we will get onto, later on, another aaS we will look to cover over the next 7 days is FaaS (Functions as a Service) where maybe you do not need a running system up all the time and you just want a function to be executed as and when.
|
||||
|
||||
There are many ways in which the public cloud can provide abstraction layers of control that you wish to pass up and pay for.
|
||||
|
||||
|
@ -9,11 +9,11 @@ id: 1049039
|
||||
---
|
||||
## Microsoft Azure Security Models
|
||||
|
||||
Following on from the Microsoft Azure Overview, we are going to start with Azure Security and see where this can help in our day today. For the most part, I have found the built-in roles have been sufficient but knowing that we can create and work with many different areas of authentication and configurations. I have found Microsoft Azure to be quite advanced with its Active Directory background compared to other public clouds.
|
||||
Following on from the Microsoft Azure Overview, we are going to start with Azure Security and see where this can help in our day to day. For the most part, I have found the built-in roles have been sufficient but knowing that we can create and work with many different areas of authentication and configurations. I have found Microsoft Azure to be quite advanced with its Active Directory background compared to other public clouds.
|
||||
|
||||
## Microsoft Azure Security Models
|
||||
|
||||
This is one area that Microsoft Azure seemingly works differently from other public cloud providers, in Azure there is ALWAYS Azure AD.
|
||||
This is one area in which Microsoft Azure seemingly works differently from other public cloud providers, in Azure there is ALWAYS Azure AD.
|
||||
|
||||
### Directory Services
|
||||
|
||||
@ -104,7 +104,7 @@ We can also use the check access tab if we want to check an account against this
|
||||
|
||||
- Free tier includes continuous assessment and security recommendations.
|
||||
|
||||
- Paid plans for protected resources types (e.g. Servers, AppService, SQL, Storage, Containers, KeyVault).
|
||||
- Paid plans for protected resource types (e.g. Servers, AppService, SQL, Storage, Containers, KeyVault).
|
||||
|
||||
I have switched to another subscription to view the Azure Security Center and you can see here based on very few resources that I have some recommendations in one place.
|
||||
|
||||
@ -112,7 +112,7 @@ I have switched to another subscription to view the Azure Security Center and yo
|
||||
|
||||
### Azure Policy
|
||||
|
||||
- Azure Policy is an Azure native service that helps to enforce organizational standards and assess compliance at-scale.
|
||||
- Azure Policy is an Azure native service that helps to enforce organizational standards and assess compliance at scale.
|
||||
|
||||
- Integrated into Microsoft Defender for Cloud. Azure Policy audits non-compliant resources and applies remediation.
|
||||
|
||||
@ -120,7 +120,7 @@ I have switched to another subscription to view the Azure Security Center and yo
|
||||
|
||||
- Uses JSON format to store evaluation logic and determine whether a resource is compliant or not, and any actions to take for non-compliance (e.g. Audit, AuditIfNotExists, Deny, Modify, DeployIfNotExists).
|
||||
|
||||
- Free for use. The exception being Azure Arc connected resources charged per server/month for Azure Policy Guest Configuration usage.
|
||||
- Free for use. The exception is Azure Arc connected resources charged per server/month for Azure Policy Guest Configuration usage.
|
||||
|
||||
### Hands-On
|
||||
|
||||
@ -128,15 +128,15 @@ I have gone out and I have purchased www.90DaysOfDevOps.com and I would like to
|
||||
|
||||

|
||||
|
||||
With that now we can create a new user on our new Active Directory Domain.
|
||||
With that now, we can create a new user on our new Active Directory Domain.
|
||||
|
||||

|
||||
|
||||
Now we want to create a group for all of our new 90DaysOfDevOps users in one group. We can create a group as per the below, notice that I am using "Dynamic User" this means Azure AD will query user accounts and add them dynamically vs assigned which is where you manually add the user to your group.
|
||||
Now we want to create a group for all of our new 90DaysOfDevOps users in one group. We can create a group as per the below, notice that I am using "Dynamic User" which means Azure AD will query user accounts and add them dynamically vs assigned which is where you manually add the user to your group.
|
||||
|
||||

|
||||
|
||||
There are lots of options when it comes to creating your query, my plan is to simply find the principal name and make sure that the name contains @90DaysOfDevOps.com.
|
||||
There are lots of options when it comes to creating your query, I plan to simply find the principal name and make sure that the name contains @90DaysOfDevOps.com.
|
||||
|
||||

|
||||
|
||||
@ -148,7 +148,7 @@ I have since added a new user1@90DaysOfDevOps.com and if we go and check the gro
|
||||
|
||||

|
||||
|
||||
If we have this requirement x100 then we are not going to want to do this all in the console we are going to want to take advantage of either bulk options to create, invite, delete users or you are going to want to look into PowerShell to achieve this automated approach to scale.
|
||||
If we have this requirement x100 then we are not going to want to do this all in the console we are going to want to take advantage of either bulk options to create, invite, and delete users or you are going to want to look into PowerShell to achieve this automated approach to scale.
|
||||
|
||||
Now we can go to our Resource Group and specify that on the 90DaysOfDevOps resource group we want the owner to be the group we just created.
|
||||
|
||||
@ -156,15 +156,15 @@ Now we can go to our Resource Group and specify that on the 90DaysOfDevOps resou
|
||||
|
||||
We can equally go in here and deny assignments access to our resource group as well.
|
||||
|
||||
Now if we login to the Azure Portal with our new user account, you can see that we only have access to our 90DaysOfDevOps resource group and not the others seen in previous pictures because we do not have the access.
|
||||
Now if we log in to the Azure Portal with our new user account, you can see that we only have access to our 90DaysOfDevOps resource group and not the others seen in previous pictures because we do not have the access.
|
||||
|
||||

|
||||
|
||||
The above is great if this is a user that has access to resources inside of your Azure portal but not every user needs to be aware of the portal, but in order to check access we can use the [Apps Portal](https://myapps.microsoft.com/) This is a single sign on portal for us to test.
|
||||
The above is great if this is a user that has access to resources inside of your Azure portal, not every user needs to be aware of the portal, but to check access we can use the [Apps Portal](https://myapps.microsoft.com/) This is a single sign-on portal for us to test.
|
||||
|
||||

|
||||
|
||||
You are able to customise this portal with your own branding and this might be something we come back to later on.
|
||||
You can customise this portal with your branding and this might be something we come back to later on.
|
||||
|
||||
## Resources
|
||||
|
||||
|
@ -2,14 +2,14 @@
|
||||
title: '#90DaysOfDevOps - Installing & Configuring Git - Day 36'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Installing & Configuring Git
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048738
|
||||
---
|
||||
## Installing & Configuring Git
|
||||
|
||||
Git is a open source, cross platform tool for version control. If I like me you are using Ubuntu or most Linux environments you might find that you already git installed but we are going to run through the install and configuration.
|
||||
Git is a open source, cross platform tool for version control. If you are like me, using Ubuntu or most Linux environments you might find that you already have git installed but we are going to run through the install and configuration.
|
||||
|
||||
Even if you already have git installed on your system it is also a good idea to make sure we are up to date.
|
||||
|
||||
@ -136,7 +136,7 @@ Some of the major benefits of Git are:
|
||||
- Flexible
|
||||
- Safe & Secure
|
||||
|
||||
Unlike the Client-Server version control model, each developer downloads the the source repository meaning everything. History of commits, all the branches etc. etc.
|
||||
Unlike the Client-Server version control model, each developer downloads the source repository meaning everything. History of commits, all the branches etc.
|
||||
|
||||

|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: '#90DaysOfDevOps - The anatomy of a Docker Image - Day 45'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - The anatomy of a Docker Image
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048777
|
||||
@ -59,7 +59,7 @@ The following table shows some of the dockerfile statements we will be using or
|
||||
| COPY | To copy over files or directories from a specific location. |
|
||||
| ADD | As COPY, but also able to handle remote URLs and unpack compressed files. |
|
||||
| ENTRYPOINT | Command that will always be executed when the container starts. If not specified, the default is /bin/sh -c |
|
||||
| .md | Arguments passed to the entrypoint. If ENTRYPOINT is not set (defaults to /bin/sh -c), the .mdwill be the commands the container executes. |
|
||||
| CMD | Arguments passed to the entrypoint. If ENTRYPOINT is not set (defaults to /bin/sh -c), the CMD will be the commands the container executes. |
|
||||
| EXPOSE | To define which port through which to access your container application. |
|
||||
| LABEL | To add metadata to the image. |
|
||||
|
||||
|
@ -23,7 +23,7 @@ I am going to be using a baseline this [blog and repository](https://devopscube.
|
||||
|
||||
### Kubernetes Lab environment
|
||||
|
||||
I have uploaded in [Kubernetes folder](days/kubernetes) the vagrantfile that we will be using to build out our environment. Grab this and navigate to this directory in your terminal. I am again using Windows so I will be using PowerShell to perform my workstation commands with vagrant. If you do not have vagrant then you can use arkade, we covered this yesterday when installing minikube and other tools. A simple command `arkade get vagrant` should see you download and install the latest version of vagrant.
|
||||
I have uploaded in [Kubernetes folder](Kubernetes) the vagrantfile that we will be using to build out our environment. Grab this and navigate to this directory in your terminal. I am again using Windows so I will be using PowerShell to perform my workstation commands with vagrant. If you do not have vagrant then you can use arkade, we covered this yesterday when installing minikube and other tools. A simple command `arkade get vagrant` should see you download and install the latest version of vagrant.
|
||||
|
||||
When you are in your directory then you can simply run `vagrant up` and if all is configured correctly then you should see the following kick off in your terminal.
|
||||
|
||||
@ -33,7 +33,7 @@ When you are in your directory then you can simply run `vagrant up` and if all i
|
||||
|
||||

|
||||
|
||||
From the above you can see that we are going to build out 3 virtual machines, we will have a control plane node and then two worker nodes. If you head back to [Day 49](Days/day49.md) You will see some more description on these areas we see in the image.
|
||||
From the above you can see that we are going to build out 3 virtual machines, we will have a control plane node and then two worker nodes. If you head back to [Day 49](day49.md) You will see some more description on these areas we see in the image.
|
||||
|
||||
Also in the image we indicate that our kubectl access will come from outside of the cluster and hit that kube apiserver when in fact as part of the vagrant provisioning we are deploying kubectl on each of these nodes so that we can access the cluster from within each of our nodes.
|
||||
|
||||
|
@ -2,52 +2,53 @@
|
||||
title: '#90DaysOfDevOps - The Big Picture: CI/CD Pipelines - Day 70'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - The Big Picture CI/CD Pipelines
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048836
|
||||
---
|
||||
|
||||
## The Big Picture: CI/CD Pipelines
|
||||
|
||||
A CI/CD (Continous Integration/Continous Deployment) Pipeline implementation is the backbone of the modern DevOps environment.
|
||||
A CI/CD (Continous Integration/Continous Deployment) Pipeline implementation is the backbone of the modern DevOps environment.
|
||||
|
||||
It bridges the gap between development and operations by automating the build, test and deployment of applications.
|
||||
It bridges the gap between development and operations by automating the build, test and deployment of applications.
|
||||
|
||||
We covered a lot of this Continous mantra in the opening section of the challenge. But to reiterate:
|
||||
We covered a lot of this Continous mantra in the opening section of the challenge. But to reiterate:
|
||||
|
||||
Continous Integration (CI) is a more modern software development practice in which incremental code changes are made more frequently and reliabily. Automated build and test workflow steps triggered by Contininous Integration ensures that code changes being merged into the repository are reliable.
|
||||
Continous Integration (CI) is a more modern software development practice in which incremental code changes are made more frequently and reliabily. Automated build and test workflow steps triggered by Contininous Integration ensures that code changes being merged into the repository are reliable.
|
||||
|
||||
That code / Application is then delivered quickly and seamlessly as part of the Continuous Deployment process.
|
||||
That code / Application is then delivered quickly and seamlessly as part of the Continuous Deployment process.
|
||||
|
||||
### The importance of CI/CD?
|
||||
### The importance of CI/CD?
|
||||
|
||||
- Ship software quickly and efficiently
|
||||
- Ship software quickly and efficiently
|
||||
- Facilitates an effective process for getting applications to market as fast as possible
|
||||
- A continous flow of bug fixes and new features without waiting months or years for version releases.
|
||||
- A continous flow of bug fixes and new features without waiting months or years for version releases.
|
||||
|
||||
The ability for developers to make small impactful changes regular means we get faster fixes and more features quicker.
|
||||
The ability for developers to make small impactful changes regular means we get faster fixes and more features quicker.
|
||||
|
||||
### Ok, so what does this mean?
|
||||
### Ok, so what does this mean?
|
||||
|
||||
On [Day 5](day5.md) we covered a lot of the theory behind DevOps and as already mentioned here already that the CI/CD Pipeline is the backbone of the modern DevOps environment.
|
||||
On [Day 5](day5.md) we covered a lot of the theory behind DevOps and as already mentioned here already that the CI/CD Pipeline is the backbone of the modern DevOps environment.
|
||||
|
||||

|
||||
|
||||
I want to reiterate some of the key points on this image above, now that we are a little further into our journey of learning the fundamentals of DevOps.
|
||||
I want to reiterate some of the key points on this image above, now that we are a little further into our journey of learning the fundamentals of DevOps.
|
||||
|
||||
We are referring to the software development life cycle (SDLC).
|
||||
We are referring to the software development life cycle (SDLC).
|
||||
|
||||
The steps are usually written out within an infinity loop since it's a cycle that repeats forever.
|
||||
The steps are usually written out within an infinity loop since it's a cycle that repeats forever.
|
||||
|
||||
The steps in the cycle are, developers write the **code** then it gets **built** or all compiled together then it's **tested** for bugs then it's **deployed** into production where it's used (**Operated**) by end users or customers then we **monitor** and collect feedback and finally we **plan** improvements around that feedback **rinse and repeat**.
|
||||
The steps in the cycle are, developers write the **code** then it gets **built** or all compiled together then it's **tested** for bugs then it's **deployed** into production where it's used (**Operated**) by end users or customers then we **monitor** and collect feedback and finally we **plan** improvements around that feedback **rinse and repeat**.
|
||||
|
||||
### Let's go a little deeper into CI/CD
|
||||
|
||||
### CI
|
||||
|
||||
CI is a development practice that requires developers to integrate code into a shared repository several times a day.
|
||||
CI is a development practice that requires developers to integrate code into a shared repository several times a day.
|
||||
|
||||
When the code is written and pushed to a repository like github or gitlab that's where the magic begins.
|
||||
When the code is written and pushed to a repository like github or gitlab that's where the magic begins.
|
||||
|
||||

|
||||
|
||||
@ -55,61 +56,62 @@ The code is verified by an automated build which allows teams or the project own
|
||||
|
||||

|
||||
|
||||
From there the code is analysed and given a series of automated tests three examples are
|
||||
From there the code is analysed and given a series of automated tests three examples are
|
||||
|
||||
- Unit testing this tests the individual units of the source code
|
||||
- Unit testing this tests the individual units of the source code
|
||||
- Validation testing this makes sure that the software satisfies or fits the intended use
|
||||
- Format testing this checks for syntax and other formatting errors
|
||||
|
||||
These tests are created as a workflow and then are run every time you push to the master branch so pretty much every major development team has some sort of CI/CD workflow and remember on a development team the new code could be coming in from teams all over the world at different times of the day from developers working on all sorts of different projects it's more efficient to build an automated workflow of tests that make sure that everyone is on the same page before the code is accepted. It would take much longer for a human to do this each time.
|
||||
- Format testing this checks for syntax and other formatting errors
|
||||
|
||||
These tests are created as a workflow and then are run every time you push to the master branch so pretty much every major development team has some sort of CI/CD workflow and remember on a development team the new code could be coming in from teams all over the world at different times of the day from developers working on all sorts of different projects it's more efficient to build an automated workflow of tests that make sure that everyone is on the same page before the code is accepted. It would take much longer for a human to do this each time.
|
||||
|
||||

|
||||
|
||||
Once we have our tests complete and they are successful then we can compile and send to our repository. For example I am using Docker Hub but this could be anywhere that then gets leveraged for the CD aspect of the pipeline.
|
||||
Once we have our tests complete and they are successful then we can compile and send to our repository. For example I am using Docker Hub but this could be anywhere that then gets leveraged for the CD aspect of the pipeline.
|
||||
|
||||

|
||||
|
||||
So this process is obviously very much down to the software development process, we are creating our application, adding, fixing bugs etc and then updating our source control and versioning that whilst also testing.
|
||||
So this process is obviously very much down to the software development process, we are creating our application, adding, fixing bugs etc and then updating our source control and versioning that whilst also testing.
|
||||
|
||||
Moving onto the next phase is the CD element which in fact more and more is what we generally see from any off the shelf software, I would argue that we will see a trend that if we get our software from a vendor such as Oracle or Microsoft we will consume that from a Docker Hub type repository and then we would use our CD pipelines to deploy that into our environments.
|
||||
Moving onto the next phase is the CD element which in fact more and more is what we generally see from any off the shelf software, I would argue that we will see a trend that if we get our software from a vendor such as Oracle or Microsoft we will consume that from a Docker Hub type repository and then we would use our CD pipelines to deploy that into our environments.
|
||||
|
||||
### CD
|
||||
### CD
|
||||
|
||||
Now we have our tested version of our code and we are ready to deploy out into the wild and like I say, the Software vendor will run through this stage but I strongly believe this is how we will all deploy the off the shelf software we require in the future.
|
||||
Now we have our tested version of our code and we are ready to deploy out into the wild and like I say, the Software vendor will run through this stage but I strongly believe this is how we will all deploy the off the shelf software we require in the future.
|
||||
|
||||
It is now time to release our code into an environment. This is going to include Production but also likely other environments as well such as staging.
|
||||
It is now time to release our code into an environment. This is going to include Production but also likely other environments as well such as staging.
|
||||
|
||||

|
||||
|
||||
Our next step at least on Day 1 of v1 of the software deployment is we need to make sure we are pulling the correct code base to the correct environment. This could be pulling elements from the software repository (DockerHub) but it is more than likely that we are also pulling additional configuration from maybe another code repository, the configuration for the application for example. In the diagram below we are pulling the latest release of the software from DockerHub and then we are releasing this to our environments whilst possibly picking up configuration from a Git repository. Our CD tool is performing this and pushing everything to our environment.
|
||||
Our next step at least on Day 1 of v1 of the software deployment is we need to make sure we are pulling the correct code base to the correct environment. This could be pulling elements from the software repository (DockerHub) but it is more than likely that we are also pulling additional configuration from maybe another code repository, the configuration for the application for example. In the diagram below we are pulling the latest release of the software from DockerHub and then we are releasing this to our environments whilst possibly picking up configuration from a Git repository. Our CD tool is performing this and pushing everything to our environment.
|
||||
|
||||
It is most likely that this is not done at the same time. i.e we would go to a staging environment run against this with our own configuration make sure things are correct and this could be a manual step for testing or it could again be automated (lets go with automated) before then allowing this code to be deployed into production.
|
||||
It is most likely that this is not done at the same time. i.e we would go to a staging environment run against this with our own configuration make sure things are correct and this could be a manual step for testing or it could again be automated (lets go with automated) before then allowing this code to be deployed into production.
|
||||
|
||||

|
||||
|
||||
Then after this when v2 of the application comes out we rinse and repeat the steps this time we ensure our application + configuration is deployed to staging ensure everything is good and then we deploy to production.
|
||||
Then after this when v2 of the application comes out we rinse and repeat the steps this time we ensure our application + configuration is deployed to staging ensure everything is good and then we deploy to production.
|
||||
|
||||
### Why use CI/CD?
|
||||
### Why use CI/CD?
|
||||
|
||||
I think we have probably covered the benefits a number of time but it is because it automates things that otherwise would have to be done manually it finds small problems before it sneaks into the main codebase, you can probably imagine that if you push bad code out to your customers then you're going to have a bad time!
|
||||
I think we have probably covered the benefits a number of time but it is because it automates things that otherwise would have to be done manually it finds small problems before it sneaks into the main codebase, you can probably imagine that if you push bad code out to your customers then you're going to have a bad time!
|
||||
|
||||
It also helps to prevent something that we call technical debt which is the idea that since the main code repos are constantly being built upon over time then a shortcut fix taken on day one is now an exponentially more expensive fix years later because now that band-aid of a fix would be so deeply intertwined and baked into all the code bases and logic.
|
||||
It also helps to prevent something that we call technical debt which is the idea that since the main code repos are constantly being built upon over time then a shortcut fix taken on day one is now an exponentially more expensive fix years later because now that band-aid of a fix would be so deeply intertwined and baked into all the code bases and logic.
|
||||
|
||||
### Tooling
|
||||
|
||||
Like with other sections we are going to get hands on with some of the tools that achieve the CI/CD pipeline process.
|
||||
Like with other sections we are going to get hands on with some of the tools that achieve the CI/CD pipeline process.
|
||||
|
||||
I think it is also important to note that not all tools have to do both CI and CD, We will take a look at ArgoCD which you guessed it is great at the CD element of deploying our software to a Kubernetes cluster. But something like Jenkins can work across many different platforms.
|
||||
I think it is also important to note that not all tools have to do both CI and CD, We will take a look at ArgoCD which you guessed it is great at the CD element of deploying our software to a Kubernetes cluster. But something like Jenkins can work across many different platforms.
|
||||
|
||||
My plan is to look at the following:
|
||||
My plan is to look at the following:
|
||||
|
||||
- Jenkins
|
||||
- ArgoCD
|
||||
- GitHub Actions
|
||||
- Jenkins
|
||||
- ArgoCD
|
||||
- GitHub Actions
|
||||
|
||||
## Resources
|
||||
|
||||
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||
- [Introduction to Jenkins](https://www.edx.org/course/introduction-to-jenkins)
|
||||
- [Jenkins.io](https://www.jenkins.io/)
|
||||
- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
|
||||
- [ArgoCD Tutorial for Beginners](https://www.youtube.com/watch?v=MeU5_k9ssrs)
|
||||
|
@ -48,7 +48,7 @@ DevOpsは、このムーブメントの目標に到達するための一連の
|
||||
|
||||
DevOpsの観点では、**開発、テスト、デプロイメント**のすべてがDevOpsチームに集約されます。
|
||||
|
||||
最後に、これを可能な限り効果的かつ効率的にするために、**自動化**を活用しなければならないことを指摘したいと思います。 無料版のDeepL翻訳(www.DeepL.com/Translator)で翻訳しました。
|
||||
最後に、これを可能な限り効果的かつ効率的にするために、**自動化**を活用しなければならないことを指摘したいと思います。
|
||||
|
||||
## リソース
|
||||
|
||||
|
@ -1,68 +1,67 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Responsibilities of a DevOps Engineer - Day 2'
|
||||
title: '#90DaysOfDevOps - DevOpsエンジニアの責務 - 二日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Responsibilities of a DevOps Engineer
|
||||
description: 90DaysOfDevOps - DevOpsエンジニアの責務
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048699
|
||||
date: '2022-04-17T21:15:34Z'
|
||||
---
|
||||
## Responsibilities of a DevOps Engineer
|
||||
## DevOpsエンジニアの責務
|
||||
|
||||
Hopefully you are coming into this off the back of going through the resources and post on [Day1 of #90DaysOfDevOps](day01.md)
|
||||
希望的には、[#90DaysOfDevOps の一日目](day01.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.
|
||||
最初の投稿で簡単に触れましたが、このコンセプトをより深く理解し、アプリケーションを作成する際に2つの主要な部分があることを理解する必要があります。まず、ソフトウェア開発者がアプリケーションをプログラムし、それをテストする**開発**の部分があります。そして、アプリケーションをサーバーにデプロイし、維持する**運用**の部分があります。
|
||||
|
||||
## DevOps is the link between the two
|
||||
## DevOps は両者をつなぐもの
|
||||
|
||||
To get to grips with DevOps or the tasks in 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.
|
||||
DevOpsやDevOpsエンジニアが行う作業を理解するためには、ツールやプロセス、それらの概要、そしてそれらがどのように組み合わされているかを理解する必要があります。
|
||||
|
||||
Everything starts with the application! You will see so much throughout that it is all about the application when it comes to DevOps.
|
||||
すべてはアプリケーションから始まる DevOpsに関しては、アプリケーションがすべてであることがよくわかると思います。
|
||||
|
||||
Developers will create an application, this can be done with many different technology stacks and lets leave that to the imagination for now as we get into this later. This can also involve many different programming languages, build tools, code repository etc.
|
||||
開発者はアプリケーションを作成します。これは様々なテクノロジースタックを使って行うことができますが、これについては後で説明するので、今は想像にお任せします。また、多くの異なるプログラミング言語、ビルドツール、コードリポジトリなどが含まれることもあります。
|
||||
|
||||
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.
|
||||
DevOpsエンジニアとして、あなたはアプリケーションをプログラミングすることはありませんが、開発者がどのように働いているか、彼らが使っているシステム、ツール、プロセスの概念をよく理解していることが成功への鍵となります。
|
||||
|
||||
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.
|
||||
非常に高いレベルでは、アプリケーションが必要なすべてのサービスやデータサービスと対話するためにどのように構成されるかを知る必要がありますし、これをどのようにテストできるか、またはすべきかの要件も必要です。
|
||||
|
||||
The application will need to be deployed somewhere, lets 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.
|
||||
アプリケーションは、どこかに配置される必要があります。ここでは、一般的にシンプルにして、サーバーとします。このアプリケーションは、作成されたアプリケーションに応じて、顧客やエンドユーザがアクセスすることが期待されます。
|
||||
|
||||
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.
|
||||
このサーバーは、オンプレミス、パブリッククラウド、サーバーレス(ここではサーバーレスについては触れませんが、選択肢の一つであり、ますます多くの企業がこの方向に向かっています)など、どこかで実行される必要があります。この要素は、DevOpsエンジニアとして、これらのサーバーをデプロイし、設定するために、あなたに降りかかるかもしれません。
|
||||
|
||||
These servers will have to 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.
|
||||
これらのサーバーはオペレーティング・システムを実行する必要があり、一般的に言えば、これはLinuxになるのですが、このセクションまたは週で、ここで得るべき基礎知識をいくつか取り上げます。
|
||||
|
||||
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 all things DNS, DHCP, Load Balancing etc.
|
||||
また、ネットワークや環境内の他のサービスと通信する必要がある場合もあるので、ネットワーキングやその設定に関する知識も必要です。ここでもまた、DNS、DHCP、ロードバランシングなどに関する専門的なセクションでより詳しく説明します。
|
||||
|
||||
## 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.
|
||||
ネットワークやインフラの専門家である必要はありませんが、プログラミング言語の基礎知識は必要ですが、開発者である必要はありません。しかし、ある分野のスペシャリストとして入社すれば、他の分野に適応するための大きな足がかりになるでしょう。
|
||||
|
||||
You will also most likely not take over the management of these servers or the application on a daily basis.
|
||||
また、サーバーやアプリケーションの管理を日常的に行うことはほとんどないでしょう。
|
||||
|
||||
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.
|
||||
これまでサーバーについて説明してきましたが、アプリケーションはコンテナとして動作するように開発される可能性が高いです。それでも大部分はサーバ上で動作しますが、仮想化、IaaS (Cloud Infrastructure as a Service) だけでなく、コンテナ化についても理解する必要があります。
|
||||
|
||||
## High Level Overview
|
||||
## ハイレベルの概要
|
||||
|
||||
On one side we have our developers creating new features and functionality (as well as bug fixes) for the application.
|
||||
一方では、開発者がアプリケーションの新機能(およびバグフィックス)を作成しています。
|
||||
|
||||
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.
|
||||
もう一方では、このアプリケーションを実行し、必要なすべてのサービスと通信するために構成され管理される、ある種の環境、インフラストラクチャ、またはサーバーがあります。
|
||||
|
||||
The big question is how do we get those features and bug fixes into our production and make it available to those end users?
|
||||
大きな問題は、これらの機能やバグフィックスをどのように本番環境に導入し、エンドユーザーが利用できるようにするかということです。
|
||||
|
||||
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!
|
||||
新しいアプリケーションのバージョンをどのようにリリースするのでしょうか?これはDevOpsエンジニアの主なタスクの1つで、ここで重要なのは、これを1回だけ行う方法を見つけ出すことではなく、継続的に、自動化された効率的な方法で行う必要があり、テストも含める必要があります。
|
||||
|
||||
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.
|
||||
ここで、今日の学習を終了します。これが役に立つことを願っています。次の数日間で、DevOpsのいくつかの領域をもう少し深く掘り下げていきます。そして、ツールやプロセス、これらの利点について深く掘り下げたセクションに入ります。
|
||||
|
||||
## Resources
|
||||
## 参考情報
|
||||
|
||||
I am always open to adding additional resources to these readme files as it is here as a learning tool.
|
||||
このReadmeファイルは学習用として用意したものなので、いつでも追加リソースを受け付けています。
|
||||
私のアドバイスは、以下のビデオをすべて見ること、そして上記のテキストや説明から何かを感じ取っていただけることを願っています。
|
||||
|
||||
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).
|
||||
ここまで来れば、ここが自分の望むところかどうかが分かるはずです。それでは、[3日目](day03.md)でお会いしましょう。
|
@ -1,79 +1,82 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Application Focused - Day 3'
|
||||
title: '#90DaysOfDevOps - アプリケーションフォーカス - 3日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Application Focused
|
||||
description: 90DaysOfDevOps - アプリケーションフォーカス
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048825
|
||||
---
|
||||
## DevOps Lifecycle - Application Focused
|
||||
## DevOps ライフサイクル - アプリケーションフォーカス
|
||||
もしあなたがDevOpsエンジニアの役割を目指しているのであれば、繰り返し行うことに慣れるでしょうが、毎回常に向上させることは、物事を面白く保つもう1つのポイントです。
|
||||
|
||||
As we continue through these next few weeks we are 100% going to come across these titles (Continuous Development, Testing, Deployment, Monitor) over and over again, If you are heading towards the DevOps Engineer role then repeatability will be something you will get used to but constantly enhancing each time is another thing that keeps things interesting.
|
||||
この時間では、アプリケーションの開始から終了までのハイレベルなビューを見て、一定のループのように戻ってくることにします。
|
||||
|
||||
In this hour we are going to take a look at the high level view of the application from start to finish and then back round again like a constant loop.
|
||||
### 開発
|
||||
|
||||
### Development
|
||||
Let's take a brand new example of an Application, to start with we have nothing created, maybe as a developer you have to discuss with your client or end user on the requirements and come up with some sort of plan or requirements for your Application. We then need to create from the requirements our brand new application.
|
||||
開発者として、クライアントやエンドユーザーと要件について話し合い、アプリケーションのためのある種の計画や要件を考え出さなければならないかもしれません。次に、要件から新しいアプリケーションを作成する必要があります。
|
||||
|
||||
In regards to tooling at this stage there is no real requirement here other than choosing your IDE and the programming language you wish to use to write your application.
|
||||
この段階では、IDEとアプリケーションを書くのに使いたいプログラミング言語を選択する以外には、ツールに関する本当の要件はありません。
|
||||
|
||||
As a DevOps engineer, remember you are probably not the one creating this plan or coding the application for the end user, this will be a skilled developer.
|
||||
DevOpsエンジニアとして、あなたはおそらくこの計画を作成したり、エンド・ユーザーのためにアプリケーションをコーディングしたりする人ではないことを忘れないでください。
|
||||
|
||||
But it also would not hurt for you to be able to read some of the code so that you can make the best infrastructure decisions moving forward for your application.
|
||||
しかし、アプリケーションのために前進する最適なインフラストラクチャの決定を行うことができるように、コードの一部を読むことができても問題ないでしょう。
|
||||
|
||||
We previously mentioned that this application can be written in any language. Importantly this should be maintained using a version control system, this is something we will cover also in detail later on and in particular we will dive into **Git**.
|
||||
このアプリケーションはどのような言語でも書けることは前述しました。重要なのは、バージョン管理システムを使って保守することです。これは後ほど詳しく説明し、特に **Git** について掘り下げます。
|
||||
|
||||
It is also likely that it will not be one developer working on this project although this could be the case but even so best practices would require a code repository to store and collaborate on the code, this could be private or public and could be hosted or privately deployed generally speaking you would hear the likes of **GitHub or GitLab** being used as a code repository. Again we will cover these as part of our section on **Git** later on.
|
||||
また、このプロジェクトに取り組む開発者は一人ではないと思われますが、それでもベストプラクティスでは、コードを保存して共同作業するためのコードリポジトリが必要です。これはプライベートでもパブリックでもよく、ホスティングでもプライベートでも展開できます。後ほど、**Git**のセクションの一部として、これらもカバーします。
|
||||
|
||||
|
||||
### Testing
|
||||
At this stage we have our requirements and we have our application being developed. But we need to make sure we are testing our code in all the various different environments that we have available to us or specifically maybe to the programming language chosen.
|
||||
### テスト
|
||||
|
||||
This phase enables QA to test for bugs, more frequently we see containers being used for simulating the test environment which overall can improve on cost overheads of physical or cloud infrastructure.
|
||||
この段階で、私たちは要件を満たし、アプリケーションを開発することができます。しかし、私たちは、私たちが利用可能なすべての様々な異なる環境、または特に選択したプログラミング言語で私たちのコードをテストしていることを確認する必要があります。
|
||||
|
||||
This phase is also likely going to be automated as part of the next area which is Continuous Integration.
|
||||
このフェーズでは、QAがバグをテストすることができます。テスト環境のシミュレーションにコンテナが使用されることが多くなり、物理インフラやクラウドインフラのコスト・オーバーヘッドを全体的に改善することができます。
|
||||
|
||||
The ability to automate this testing vs 10s,100s or even 1000s of QA engineers having to do this manually speaks for itself, these engineers can focus on something else within the stack to ensure you are moving faster and developing more functionality vs testing bugs and software which tends to be the hold up on most traditional software releases that use a waterfall methodology.
|
||||
このフェーズは、次の継続的インテグレーション(Continuous Integration)の一部として自動化される可能性も高い。
|
||||
|
||||
### Integration
|
||||
QAエンジニアが数十人、数百人、あるいは千人単位で手作業でテストを行うのに対して、このテストを自動化できることは、それを物語っています。このエンジニアはスタック内で他のことに集中できるので、ウォーターフォール手法を使用した従来のソフトウェアのリリースで滞りがちだったバグやソフトウェアのテストではなく、より速く、より機能的に開発することが可能になります。
|
||||
|
||||
Quite importantly Integration is at the middle of the DevOps lifecycle. It is the practice of in which developers require to commit changes to the source code more frequently. This could be on a daily or weekly basis.
|
||||
### インテグレーション
|
||||
|
||||
With every commit your application can go through the automated testing phases and this allows for early detection of issues or bugs before the next phase.
|
||||
インテグレーションは、DevOpsのライフサイクルの中で最も重要なものです。これは、開発者がより頻繁にソースコードに変更をコミットすることを必要とするプラクティスである。これは、日次または週次ベースで可能です。
|
||||
|
||||
Now you might at this stage be saying "but we don't create applications, we buy it off the shelf from a software vendor" Don't worry many companies do this and will continue to do this and it will be the software vendor that is concentrating on the above 3 phases but you might want to still adopt the final phase as this will enable for faster and more efficient deployments of your off the shelf deployments.
|
||||
コミットするたびに、アプリケーションは自動テストフェーズを通過することができ、次のフェーズの前に問題やバグを早期に発見することができるようになります。
|
||||
|
||||
I would also suggest just having this above knowledge is very important as you might buy off the shelf software today, but what about tomorrow or down the line... next job maybe?
|
||||
この段階で、「でも、うちはアプリケーションを作らずに、ソフトウェアベンダーから既製品を買っています」と言うかもしれません。心配しないでください。多くの企業がそうしていますし、これからもそうするでしょう。
|
||||
|
||||
### Deployment
|
||||
Ok so we have our application built and tested against the requirements of our end user and we now need to go ahead and deploy this application into production for our end users to consume.
|
||||
また、このような知識を持つことは非常に重要です。今日は既製のソフトウェアを購入するかもしれませんが、明日やその先...次の仕事ではどうでしょうか?
|
||||
|
||||
This is the stage where the code is deployed to the production servers, now this is where things get extremely interesting and it is where the rest of our 86 days dives deeper into these areas. Because different applications require different possibly hardware or configurations. This is where **Application Configuration Management** and **Infrastructure as Code** could play a key part in your DevOps lifecycle. It might be that your application is **Containerised** but also available to run on a virtual machine. Which then also leads us onto platforms like **Kubernetes** which would be orchestrating those containers and making sure you have the desired state available to your end users.
|
||||
### デプロイメント
|
||||
|
||||
All of these bold topics we will go into more detail over the next few weeks to get a better foundational knowledge of what they are and when to use them.
|
||||
さて、私たちはアプリケーションを構築し、エンドユーザーの要求に対してテストを行いました。
|
||||
|
||||
### Monitoring
|
||||
これは、コードを本番サーバーにデプロイする段階ですが、ここが非常に面白くなるところで、86日間の残りの時間は、これらの領域に深く潜っていきます。なぜなら、アプリケーションによって、必要となるハードウェアや構成が異なるからです。そこで、**アプリケーション構成管理**と**Infrastructure as Code**がDevOpsライフサイクルの中で重要な役割を果たすことになります。アプリケーションは**コンテナ化**されているかもしれませんが、仮想マシン上で実行することも可能です。そして、コンテナをオーケストレーションし、エンドユーザーが望む状態を利用できるようにする **Kubernetes** のようなプラットフォームにもつながっていくのです。
|
||||
|
||||
Things are moving fast here and we have our Application that we are continuously updating with new features and functionality and we have our testing making sure no gremlins are being found. We have the application running in our environment that can be continually keeping the required configuration and performance.
|
||||
これらの大胆なトピックはすべて、今後数週間でさらに詳しく説明し、それらが何であり、どのような場合に使用するのかについての基礎知識を深めていきます。
|
||||
|
||||
But now we need to be sure that our end users are getting the experience they require. Here we need to make sure that our Application Performance is continuously being monitored, this phase is going to allow your developers to make better decisions about enhancements to the application in future releases to better serve the end users.
|
||||
### モニタリング
|
||||
|
||||
This section is also where we are going to capture that feedback wheel about the features that have been implemented and how the end users would like to make these better for them.
|
||||
私たちは、新しい機能や特徴を持つアプリケーションを継続的に更新し、グレムリンが発見されていないことを確認するためのテストを行っています。必要な構成とパフォーマンスを継続的に維持できる環境で、アプリケーションを実行させています。
|
||||
|
||||
Reliability is a key factor here as well, at the end of the day we want our Application to be available all the time it is required. This then lends to other **observability, security and data management** areas that should be continuously monitored and feedback can always be used to better enhance, update and release the application continuously.
|
||||
しかし、今度は、エンドユーザーが必要とする体験を得られるかどうかを確認する必要があります。ここでは、アプリケーションのパフォーマンスが継続的に監視されていることを確認する必要があります。このフェーズでは、開発者が将来のリリースでアプリケーションを強化し、エンドユーザにより良いサービスを提供するためのより良い決定を下すことができるようになります。
|
||||
|
||||
Some input from the community here specifcally [@_ediri](https://twitter.com/_ediri) mentioned also part of this continous process we should also have the FinOps teams involved. Apps & Data are running and stored somewhere you should be monitoring this continously to make sure if things change from a resources point of view your costs are not causing some major financial pain on your Cloud Bills.
|
||||
また、このセクションでは、実装された機能と、エンドユーザがそれらをどのように改善したいかについてのフィードバックの輪を捉えるところでもあります。
|
||||
|
||||
I think it is also a good time to bring up the "DevOps Engineer" mentions above, albeit there are many DevOps Engineer positions in the wild that people hold, this is not really the ideal way of positioning the process of DevOps. What I mean is from speaking to others in the community the title of DevOps Engineer should not be the goal for anyone because really any position should be adopting DevOps processes and the culture explained here. DevOps should be used in many different positions such as Cloud-Native engineer/architect, virtualisation admin, cloud architect/engineer, infrastructure admin. This is to name a few but the reason for using DevOps Engineer above was really to highlight the scope or the process used by any of the above positions and more.
|
||||
信頼性はここでも重要な要素です。結局のところ、私たちはアプリケーションが必要とされるときはいつでも利用できるようにしたいのです。これは、継続的に監視されるべき他の**監視性、セキュリティ、およびデータ管理**の分野につながり、フィードバックは常に、アプリケーションを継続的に強化、更新、およびリリースするために使用することができます。
|
||||
|
||||
## Resources
|
||||
この継続的なプロセスには、FinOpsチームも関与すべきであると、特に[@_ediri](https://twitter.com/_ediri)はコミュニティからのいくつかの意見に言及しました。アプリとデータはどこかで実行され、保存されています。リソースの観点から物事が変化した場合、そのコストがクラウド請求書に大きな財務的苦痛を与えていないことを確認するために、これを継続的に監視する必要があります。
|
||||
|
||||
I am always open to adding additional resources to these readme files as it is here as a learning tool.
|
||||
また、上記の「DevOpsエンジニア」の話を持ち出す良い機会だと思います。世間には多くのDevOpsエンジニアのポジションがありますが、これはDevOpsのプロセスを位置づける上で理想的な方法ではありません。私が言いたいのは、コミュニティの他の人たちと話すと、DevOpsエンジニアという肩書きは誰にとってもゴールではないはずだということです。なぜなら、本当にどんなポジションでも、DevOpsプロセスやここで説明したカルチャーを採用すべきだからです。DevOpsは、Cloud-Nativeエンジニア/アーキテクト、仮想化管理者、クラウドアーキテクト/エンジニア、インフラ管理者など、様々なポジションで使用されるべきものです。これはほんの一例ですが、上記のDevOps Engineerを使用した理由は、上記のポジションやその他のポジションで使用される範囲やプロセスを強調するためです。
|
||||
無料版のDeepL翻訳(www.DeepL.com/Translator)で翻訳しました。
|
||||
|
||||
My advice is to watch all of the below and hopefully you also picked something up from the text and explanations above.
|
||||
## リソース
|
||||
|
||||
- [Continuous Development](https://www.youtube.com/watch?v=UnjwVYAN7Ns) I will also add that this is focused on manufacturing but the lean culture can be closely followed with DevOps.
|
||||
このReadmeファイルは学習用として用意したものなので、いつでも追加リソースを受け付けています。
|
||||
|
||||
私のアドバイスは、以下のビデオをすべて見ること、そして上記のテキストや説明から何かを感じ取っていただけることを願っています。
|
||||
|
||||
- [Continuous Development](https://www.youtube.com/watch?v=UnjwVYAN7Ns) I will also add that this is focused on manufacturing but the lean culture can be closely followed with DevOps.
|
||||
- [Continuous Testing - IBM YouTube](https://www.youtube.com/watch?v=RYQbmjLgubM)
|
||||
- [Continuous Integration - IBM YouTube](https://www.youtube.com/watch?v=1er2cjUq1UI)
|
||||
- [Continuous Monitoring](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
|
||||
@ -81,4 +84,4 @@ My advice is to watch all of the below and hopefully you also picked something u
|
||||
- [FinOps Foundation - What is FinOps](https://www.finops.org/introduction/what-is-finops/)
|
||||
- [**NOT FREE** The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win](https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO)
|
||||
|
||||
If you made it this far then you will know if this is where you want to be or not. See you on [Day 4](day04.md).
|
||||
ここまで来れば、ここが自分の居場所かどうかが分かるはずです。では、[4日目](day04.md)でお会いしましょう。
|
||||
|
@ -1,99 +1,98 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - DevOps & Agile - Day 4'
|
||||
title: '#90DaysOfDevOps - DevOps & アジャイル - 四日目'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - DevOps & Agile
|
||||
description: 90DaysOfDevOps - DevOps & アジャイル
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048700
|
||||
---
|
||||
|
||||
## DevOps & Agile
|
||||
## DevOps & アジャイル
|
||||
|
||||
Do you know the difference between DevOps and Agile? They were formed as standalone concepts. But now the two terms are getting fused.
|
||||
DevOpsとアジャイルの違いをご存知でしょうか?これらは独立した概念として形成されていました。しかし、今ではこの2つの用語は融合しつつある。
|
||||
|
||||
In this post, we will examine the crucial differences between Agile and DevOps and find out why the two are connected so tightly.
|
||||
この記事では、アジャイルとDevOpsの決定的な違いを検証し、なぜこの2つが密接に結びついているのかを探っていきます。
|
||||
|
||||
I think a good place to start is understanding a little more about a common angle I have seen in learning this area and that is DevOps vs Agile, even though they have similar goals and processes. In this section, I am going to summarise this hopefully.
|
||||
私がこの分野を学ぶ上でよく目にする角度、それはDevOps vs アジャイルで、両者は同じような目標とプロセスを持っているにもかかわらず、もう少し理解することから始めると良いと思います。このセクションでは、このことを希望的にまとめていこうと思います。
|
||||
|
||||
Let's start with definitions.
|
||||
まず、定義から始めましょう。
|
||||
|
||||
### Agile Development
|
||||
|
||||
Agile is an approach that focuses on delivering small results faster rather than releasing one big interaction of the product; software is developed in iterations. The team releases a new version every week or month with incremental updates. The final goal of Agile is to deliver an optimal experience to the end-users.
|
||||
### アジャイル開発
|
||||
|
||||
アジャイルは、製品の1つの大きなインタラクションをリリースするのではなく、小さな成果をより早く提供することに焦点を当てたアプローチであり、ソフトウェアはイテレーションで開発される。チームは、毎週または毎月、インクリメンタルアップデートで新バージョンをリリースします。アジャイルの最終目標は、エンドユーザーに最適なエクスペリエンスを提供することです。
|
||||
|
||||
### DevOps
|
||||
|
||||
We have been covering this for the past few days with a few different ways of describing the end goals of DevOps. DevOps usually describes software development
|
||||
and delivery practices based on cooperation between software developers and operations specialists. The main DevOps benefits are delivering a simplified development process and minimising miscommunication.
|
||||
ここ数日、DevOpsの最終目標を説明するいくつかの異なる方法で、これを取り上げてきました。DevOpsは通常、ソフトウェア開発者と運用スペシャリストの協力に基づくソフトウェア開発とデリバリープラクティスを説明するものです。DevOpsの主な利点は、簡素化された開発プロセスを提供し、ミスコミュニケーションを最小限に抑えることです。
|
||||
|
||||
## What is the difference between Agile and DevOps
|
||||
## アジャイルとDevOpsの違いとは
|
||||
|
||||
The difference is mainly the preoccupations. Agile and DevOps have different preoccupations but they are helping each other. Agile wants short iteration, which is only possible with the automation that DevOps brings. Agile wants the customer to try a specific version and quickly give feedback which is only possible if DevOps make the creation of new environment easy.
|
||||
その違いは、主に先入観です。アジャイルとDevOpsは、それぞれ異なる関心事を持っていますが、互いに助け合っているのです。アジャイルは短いイテレーションを求めますが、それはDevOpsがもたらす自動化によってのみ可能になります。アジャイルは、顧客が特定のバージョンを試し、すぐにフィードバックを得られることを望んでいるが、これはDevOpsが新しい環境の作成を容易にする場合にのみ可能です。
|
||||
|
||||
### Different participants
|
||||
### 参加者が異なる
|
||||
|
||||
Agile focuses on optimising communication between end-users and developers while DevOps targets developers and operation team members. We could say that agile is outward-oriented towards customers whereas DevOps is a set of internal practices.
|
||||
アジャイルはエンドユーザーと開発者のコミュニケーションの最適化に焦点を当て、DevOpsは開発者と運用チームメンバーを対象としています。アジャイルは顧客に対して外向きであるのに対し、DevOpsは社内向けのプラクティスの集合体であるとも言えます。
|
||||
|
||||
### Team
|
||||
### チーム
|
||||
|
||||
Agile usually applies to software developers and project managers. The competencies of DevOps engineers lie in the intersection of development, QA (quality assurance) and operations as they are involved in all stages of the product cycle and are part of the Agile team.
|
||||
アジャイルは通常、ソフトウェア開発者とプロジェクトマネージャに適用されます。DevOpsエンジニアのコンピテンシーは、製品サイクルの全段階に関わり、アジャイルチームの一員であることから、開発、QA(品質保証)、運用が交差するところにあります。
|
||||
|
||||
### Applied Frameworks
|
||||
### 応用フレームワーク
|
||||
|
||||
Agile has a lot of management frameworks to achieve flexibility and transparency: Scrum > Kanban > Lean > Extreme > Crystal > Dynamic > Feature-Driven. DevOps focuses on the development approach in collaboration but doesn't offer specific methodologies. However, DevOps promote practices like Infrastructure as Code, Architecture as Code, Monitoring, Self Healing, end to end test automation ... But per se this is not a framework, rather practices.
|
||||
アジャイルには、柔軟性と透明性を実現するために、多くのマネジメントフレームワークがあります。スクラム>カンバン>リーン>エクストリーム>クリスタル>ダイナミック>フィーチャードリブン。DevOpsは、コラボレーションによる開発アプローチに焦点を当てていますが、特定の方法論を提供しているわけではありません。しかし、DevOpsは、Infrastructure as Code、Architecture as Code、モニタリング、セルフヒーリング、エンドツーエンドのテスト自動化などのプラクティスを推進している。しかし、それ自体はフレームワークではなく、むしろプラクティスです。
|
||||
|
||||
### Feedback
|
||||
### フィードバック
|
||||
|
||||
In Agile the main source of feedback is the end-user while in DevOps the feedback from stakeholders and the team itself has a higher priority.
|
||||
アジャイルではエンドユーザーが主なフィードバック元ですが、DevOpsではステークホルダーやチーム自身からのフィードバックがより優先されます。
|
||||
|
||||
### Target areas
|
||||
### 対象領域
|
||||
|
||||
Agile focuses on software development more than on deployment and maintenance. DevOps focuses on software development as well but its values and tools also cover deployment and post-release stages like monitoring, high availability, security and data protection.
|
||||
アジャイルは、デプロイメントやメンテナンスよりも、ソフトウェア開発に重点を置いています。DevOpsはソフトウェア開発にも焦点を当てていますが、その価値観やツールはデプロイメントやモニタリング、高可用性、セキュリティ、データ保護などのリリース後の段階も対象としています。
|
||||
|
||||
### Documentation
|
||||
### ドキュメンテーション
|
||||
|
||||
Agile prioritises flexibility and tasks at hand over documentation and monitoring. DevOps on the other hand regards project documentation as one of the essential project components.
|
||||
アジャイルは、文書化や監視よりも、柔軟性や目の前の作業を優先します。一方、DevOpsでは、プロジェクトのドキュメンテーションをプロジェクトの重要な構成要素の1つとみなしています。
|
||||
|
||||
### Risks
|
||||
### リスク
|
||||
|
||||
Agile risks derive from the flexibility of the methodology. Agile projects are difficult to predict or evaluate as priorities and requirements are continually changing.
|
||||
アジャイルのリスクは、その手法の柔軟性に由来する。アジャイルプロジェクトは、優先順位と要件が絶えず変化するため、予測や評価が困難です。
|
||||
|
||||
DevOps risks derive from a misunderstanding of the term and the lack of suitable tools. Some people see DevOps as a collection of software for the deployment and continuous integration failing to change the underlying structure of the development process.
|
||||
DevOpsのリスクは、この用語の誤解と適切なツールの欠如に由来する。一部の人々は、DevOpsをデプロイと継続的統合のためのソフトウェアの集合体であり、開発プロセスの根本的な構造を変更することはできないと見ています。
|
||||
|
||||
### The Tools Used
|
||||
### 使用ツール
|
||||
|
||||
Agile tools are focused on management communication collaboration, metrics and feedback processing. The most popular agile tools include JIRA, Trello, Slack, Zoom, SurveyMonkey and others.
|
||||
アジャイルツールは、管理コミュニケーションコラボレーション、メトリクス、フィードバック処理に重点を置いています。最も人気のあるアジャイルツールには、JIRA、Trello、Slack、Zoom、SurveyMonkeyなどがあります。
|
||||
|
||||
DevOps uses tools for team communication, software development, deployment and integration like Jenkins, GitHub Actions, BitBucket, etc. Even though agile and DevOps have slightly different focuses and scopes the key values are almost identical, therefore you can combine the two.
|
||||
DevOpsは、Jenkins、GitHub Actions、BitBucketなど、チームコミュニケーション、ソフトウェア開発、デプロイメント、統合のためのツールを使用します。アジャイルとDevOpsは、フォーカスやスコープが若干異なるものの、重要な価値はほぼ同じであるため、この2つを組み合わせることが可能です。
|
||||
|
||||
## Bring it all together… good idea or not? Discuss?
|
||||
## 全部まとめて...良いアイデアかどうか?議論する?
|
||||
|
||||
The combination of Agile and DevOps brings the following benefits you will get:
|
||||
アジャイルとDevOpsの組み合わせは、あなたが得られる次のようなメリットをもたらします。
|
||||
|
||||
- Flexible management and powerful technology.
|
||||
- Agile practices help DevOps teams to communicate their priorities more efficiently.
|
||||
- The automation cost that you have to pay for your DevOps practices is justified by your agile requirement of deploying quickly and frequently.
|
||||
- It leads to strengthening: the team adopting agile practices will improve collaboration, increase the team's motivation and decrease employee turnover rates.
|
||||
- As a result, you get better product quality.
|
||||
- 柔軟なマネジメントと強力なテクノロジー。
|
||||
- アジャイルプラクティスは、DevOpsチームが優先順位をより効率的に伝えるのに役立ちます。
|
||||
- DevOpsプラクティスのために支払わなければならない自動化コストは、迅速かつ頻繁にデプロイするというアジャイルの要件によって正当化される。
|
||||
- 強化につながる:アジャイルプラクティスを採用したチームは、コラボレーションを改善し、チームのモチベーションを高め、従業員の離職率を低下させることができます。
|
||||
- その結果、より良い製品品質を得ることができる。
|
||||
|
||||
Agile allows coming back to previous product development stages to fix errors and prevent the accumulation of technical debt. To adopt agile and DevOps
|
||||
simultaneously just follow 7 steps:
|
||||
アジャイルでは、以前の製品開発段階まで戻ってエラーを修正し、技術的負債の蓄積を防ぐことができます。アジャイルとDevOpsを同時に採用するには、7つのステップを踏むだけです。
|
||||
|
||||
1. Unite the development and operation teams.
|
||||
2. Create build and run teams, all development and operational concerns are discussed by the entire DevOps team.
|
||||
3. Change your approach to sprints, and assign priority ratings to offer DevOps tasks that have the same value than development tasks. Encourage development and operations teams to exchange their opinion on other teams workflow and possible issues.
|
||||
4. Include QA in all development stages.
|
||||
5. Choose the right tools.
|
||||
6. Automate everything you can.
|
||||
7. Measure and control by using tangible numeric deliverables.
|
||||
1. 開発チームと運用チームを統合する
|
||||
2. ビルドと実行のチームを作り、開発と運用に関するすべての問題をDevOpsチーム全体で議論する
|
||||
3. スプリントへのアプローチを変更し、開発タスクと同じ価値を持つDevOpsタスクを提供するために、優先順位の評価を割り当てる。開発チームと運用チームが、他のチームのワークフローや考えられる問題について意見交換することを奨励する
|
||||
4. QAをすべての開発ステージに含める
|
||||
5. 適切なツールを選択する
|
||||
6. できることはすべて自動化する
|
||||
7. 具体的な数値化された成果物を用いて、測定と管理を行う
|
||||
|
||||
What do you think? Do you have different views? I want to hear from Developers, Operations, QA or anyone that has a better understanding of Agile and DevOps that can pass comments and feedback on this?
|
||||
いかがでしょうか?異なる見解を持っていますか?開発者、オペレーション、QA、あるいは、アジャイルとDevOpsをよりよく理解している人からのコメントやフィードバックが欲しいのですが。
|
||||
|
||||
### Resources
|
||||
### リソース
|
||||
|
||||
- [DevOps for Developers – Day in the Life: DevOps Engineer in 2021](https://www.youtube.com/watch?v=2JymM0YoqGA)
|
||||
- [3 Things I wish I knew as a DevOps Engineer](https://www.youtube.com/watch?v=udRNM7YRdY4)
|
||||
- [How to become a DevOps Engineer feat. Shawn Powers](https://www.youtube.com/watch?v=kDQMjAQNvY4)
|
||||
|
||||
If you made it this far then you will know if this is where you want to be or not. See you on [Day 5](day05.md).
|
||||
ここまで来れば、ここが自分の望むところかどうかが分かるはずです。[5日目](day05.md)でお会いしましょう。
|
||||
|
@ -16,11 +16,11 @@ English Version | [中文版本](zh_cn/README.md) | [繁體中文版本](zh_tw/R
|
||||
|
||||
## 進捗
|
||||
|
||||
- [✔️] ♾️ 1 > [Introduction](Days/day01.md)
|
||||
- [✔️] ♾️ 1 > [はじめに](Days/day01.md)
|
||||
|
||||
### DevOpsとは何か、なぜ使うのか
|
||||
|
||||
- [✔️] ♾️ 2 > [Responsibilities of a DevOps Engineer](Days/day02.md)
|
||||
- [✔️] ♾️ 2 > [DevOpsエンジニアの責務](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)
|
||||
|
Loading…
Reference in New Issue
Block a user