Welcome back to the Linux Foundation Certified IT Associate practice course. In this module we're going to look at DevOps. So there's a section on the exam that focuses on DevOps fundamentals and we'll talk about that here. When we're all done, I want you to be able to describe DevOps basics, you should be able to describe Containers, discuss Deployment Environments and lastly utilize basic Git commands. All right, so DevOps is the combination of cultural philosophies, practices and tools that increase an organization's ability to deliver applications and services at higher speeds than traditional software development methodology, right? You see this all the time using your web browser, right? You see new versions of your web browser every couple of weeks, right? That's because companies like Google and Microsoft have adopted DevOps around that software so I can get new features out there quicker, right? And so this has been adopted by lots and lots of different software developers, all right? So some goals here are speed. You want to move at a high rate so you can innovate faster and adopt to changing markets quicker, right? If your competition adds a feature and you're like a web browser, you want to get that a similar feature out there, right? You want to grow more efficiently. Rapid delivery, you want to increase the frequency and pace of releases to innovate and improve the product faster. Reliability, you want to ensure the quality of application updates and infrastructure changes so you can reliably deliver at a more rapid pace while maintaining a positive experience for the end-users. So in the old days we used a pattern called waterfall. First offered it up where we would have a block of time. Weeks and weeks where we specify what we're going to build. Then we have months where we build it and then we have up months where we test it and then we finally release it to the customer. But the idea here is to shorten these cycles have more updates so we can innovate faster. You're seeing that through these goals. The next one is scale. We want to operate and manage infrastructure development processes at scale. What that means is we want to be able to add developers, testers. We want to be able to service more users. We want to improve collaboration. We want to build more effective teams under a DevOps cultural model and emphasizing ownership and accountability values. We want security, right? We want to maintain control and preserve compliance while the team moves faster, right? That's hard. All right, so now let's look at some environmental things. So virtual machines, right? Essentially virtual machines are emulations of a computer system or a virtual computer system. So VMs, virtual machines run a complete operating system including its own kernel. We talked earlier in the cloud section about infrastructures of service. Often infrastructure is virtual machines. Containers are isolated lightweght silo for running an application on the host operating system. So often containers are a substitute for virtual machines and they tend to work better for DevOps. Containers build on top of the host operating systems kernel. And the hosting container OSs must be the same, okay? So what that means is essentially, instead of having your own operating system, you're working within the operating system. This makes it lighter weight, okay? So some benefits of containers for DevOps, it's less overhead. So containers are typically faster than virtual machines. Reproducibility, containers are much easier to reproduce. They're immutable, by default, containers are immutable, which means they aren't changeable. So essentially spin one up, you make changes the environment but you don't save those changes. So this is very helpful for software testing where you always start back in the same state. So, if I find a bug, it's easier for someone else to see it because they'll start in the same state. I haven't mutated the environment. All right, so Docker is the primary container environment out there. And a Dockerfile is simply a text based script of instructions that is used to create a container image. The file name is Docker file and it's a step by step set of instructions. So it provides a set of standard instructions to be used by Docker file, like FROM, COPY, RUN, ENV, EXPOSE, CMD. And essentially these are Linux commands. So you're starting from a set image. You then install software and run commands. And Docker will build a Docker image from this file. This makes it easy to reproduce because it's just a text file. And there's something called dockerhub. This is a service provided by Docker for finding and sharing container images with your team. Is the world's largest repository of container images with an array of content sources including container community developers, open source projects and ISVs. Independent software vendors building and distributing their code and containers. So you can give someone a container, that's the environment within which you want them to run your code. Used to get access to free public repositories for storing and sharing images or they can choose a subscription plan for private repositories. All right, let's talk now about version control. Version control is a method or system that organizes various project files and protects modifications to those files. So VCS stands for a version control system, it provides a common central place to store and merge project files. So the latest project version is accessible to the people who need it. Git is a version control system that was created by Linus Torvalds. The same person who created Linux and it's essentially a distributed version control system. So there's several components of Git. You have a working directory. This is typically a home subdirectory where all source files are created, modified and reviewed. You have a staging area where hidden subdirectory has a .git name, remember the dot means it's a hidden file. This is created by the Git init command. So when you want to create a new project, you are git init. And the working directory source files are registered in this area via the git add command. You have a local repository which contains each project's files history. And then the remote repository, this is typically a cloud based location. All right, so some git setup commands. Git init, this is how you initialize an existing directory as a git repository. Git clone, this is how you retrieve an entire repository from a hosted location via URL. So if I'm starting out a new project, I'll run git init. If I'm trying to pull down the source code to a machine from the cloud, I'll run git clone. All right, and let's just go over a couple commit commands. So git status is going to show modified files in the working directory that are staged for our next commit. Git add is going to add a file as it looks now. At the point when you run the git add command to the next commit. And then git commit where you can put a descriptive message, commits, the stage content as a new commit snapshot. High level review here. Goal of DevOps is to innovate faster. Another goal of DevOps is improved collaboration with your team. And the third goal of DevOps is to improve reliability of the software being developed, all right? I'll see you in the demo.
