




























































Besser lernen dank der zahlreichen Ressourcen auf Docsity
Heimse Punkte ein, indem du anderen Studierenden hilfst oder erwirb Punkte mit einem Premium-Abo
Prüfungen vorbereiten
Besser lernen dank der zahlreichen Ressourcen auf Docsity
Download-Punkte bekommen.
Heimse Punkte ein, indem du anderen Studierenden hilfst oder erwirb Punkte mit einem Premium-Abo
JNCIA DevOps summary notes for review the exam topics
Art: Zusammenfassungen
1 / 68
Diese Seite wird in der Vorschau nicht angezeigt
Lass dir nichts Wichtiges entgehen!





























































Traditional Network Operations Traditional computer networks were designed and operated as a set of individual components and services. In these networks, new services are implemented with manual configuration and service provisioning often using a device-level CLI. New services require new equipment and network design Incidents resolved by human intervention Slow, unreliable, does not scale Modern Network Operations To deploy applications at scale, network and service configuration must be automated. Rapid, automated, and scalable service provisioning Virtualization Private/Public/Hybrid Cloud Analytics NFV is a conceptual framework wherein the network appliance is replaced by VMs. Virtualized network functions (VNFs) are the actual functions provided: Security Routing Switching Networking is a software project Reduces costs Increases speed and scale of service delivery Bring characteristics such as Version control, code review, test before deploy, and so on. Traditional Software Development Model The classical approach to software development is summarized by what is called waterfall model (from the 1970s). Collect requirements for the new software before the software design process begins
Flow Feedback Continous experimentation and learning We will discuss more later in this course. Accelerate’s Technical and Management Practices We won’t cover this at all in this course CALMS: A Principle-based DevOps Framework Culture : A DevOps culture seeks to push decision-making responsibility as close to the edge (autonomy) as opposed to centralizing all decision-making (Command&Control). Automation: Teams undertaking a DevOps transformation should be devoted to automating as many manual tasks as possible, especially with respect to continuous integration (CI) and test automation. Lean: Lean seeks to achieve FLOW – the smooth transition of work from one “work centre” to the next, in the minimum time. Ideally with as few queues/buffers as possible. Measurement: The organization is devoted to collecting data on their processes, deployments, etc., in order to understand their current capabilities and where improvements could be achieved. Sharing: a focus on breaking down silos between departments and sharing knowledge and best practice. DevOps Principles DevOps is a combination of technologies, design concepts, mentalities, and ideals that enable high-performing IT teams to move quickly while maintaining stability. DevOps aims to align technology, design, and processes Unifies development, operation, and other teams Enables communication, collaboration, and integration Influenced by lean manufacturing principles Leverages automation and orchestration Easily roll back changes if errors are detected Automation and orchestration tools: Ansible, Puppet, Chef, and Salt
Aligns the development and operations team’s competing goals Development is focused on creating new features Operations is focused on the stability of existing services Enables the development of code in a controlled, reliable manner Increases organizational performance Improves application quality and security
IaC term is used both inside and outside of DevOps circle. IaC is a very popular method to manage cloud-based resources because it provides complete infrastructure lifecycle management. It deploys new virtual servers, applications, and networks using code. The typical workflow is: Code created Code stored in a VCS The device code goes through an automated code review process Integrate back into the primary code branch Code is deployed
CI is a practice of frequently committing the code to a shared central repository (VCS) and automating the build and test process of the code each time someone pushes new code into the repository. Primary code branch remains theoretically production-ready Quality, compliance, and security testing are performed at each step of the process. Continuous Delivery and Continuous Deployment These two are natural extensions of CI which are often used to describe the DevOps model. Continuous Delivery: makes sure that the code is ready to deploy at any time. Continuous Delivery is required for Continuous Deployment Continous Deployment: This is a way to automate the code deployment
DevOps can be implemented differently depending on the use case. Google’s Site Reliability Engineering (SRE) Specific implementation of DevOps with some extensions Network Reliability Engineering (NRE) DevOps implementation for networking Networking is inseparable from connected systems and applications Embraces failure as a way to ensure that the same error does not happen again Relies on proactive testing
Put in practice by NRE Pipeline reduces the time between design and deployment Change, in the form of code, is committed to a VCS In the design change stage, the network architects and engineers, based on business needs and customer feedback, decide what change is needed in the network In the commit change to VCS stage, the change, in the form of code, is committed to a VCS In the notify and peer review stage, the team is notified of the proposed change, and team members review and approve or reject the change In the automated testing stage, the tests run automatically, ideally in separate testing and staging environments In the automated deployment stage, the change is deployed (committed) to production. The team is notified about deployment success or failure. Failed deployments can be rolled back In the continuous monitoring stage, the network telemetry is collected and analyzed to provide real-time network performance indicators. The telemetry is compared to service-level indicators and is used to make reactive or proactive adjustments to the network Finally, in the continuous improvement stage, the failure is viewed as an opportunity to improve. Feedback is encouraged, and is used to optimize the overall system performance.
NETCONF is used to access the Junos XML API over the network RFC 6241 NETCONF is Juniper’s automation protocol of choice Supported on all Junos devices Fundation upon which many Juniper automation technologies are built including: PyEZ, YANG, and OpenConfig In most cases, NETCONF uses SSH as the transport protocol although TLS can be also used. REST API
A REST API is used to retrieve, transfer, and manipulate data using HTTP(s). REST clients use HTTP methods to perform actions on the REST server. REST is considered stateless as no client’s state information is stored on the REST server Each HTTP operation is independent All session is maintained on the REST client A REST API for Junos Supported on SRX, MX, PTX, QFX, and T series platforms The example below is equivalent to a CLI show version command
Connect to Junos OS devices and execute Junos remote procedure calls (RPCs) NETCONF and SSH are not required Retrieve data in plain text, JSON, or XML formats Junos devices provide a browser-based REST API explorer Enable Junos device management On-Box Junos Scripts You can customize the behaviour of a device with commit, operation, event, and SNMP scripts that rune on the Junos device. These scripts take XML input, process it, call the functions, and output the instructions to Junos. The programming languages used for Hunos on-box scripting include:
Enables you to avoid writing complex scripts Uses YAML files Does not require an agent on the managed devices Performs operational and configuration tasks on Junos devices Uses NETCONF and the Junos XML API
Purchased by VMware in 2020. Python-based and utilizes a Salt Proxy minion to connect to Junos devices
Enables you to define the desired state of a system and enforce that state on managed devices Used to execute commands on remote devices Able to perform event-driven closed-loop automation
Puppet is deployed using a client-server model that manages one or more agent nodes Puppet manifest file describes the desired configuration. Puppet server compiles the manifests into catalogues The puppet client periodically retrieves the catalogue and applies necessary changes Puppet is based on Ruby programming language Install a jpuppet module on the Junos devices
Chef written in Ruby Automates the provisioning and management of computing, networking, and storage resources Transforms code into infrastructure and reduces the risk of human error Cookbooks are applied to the nodes in the infrastructure
Commits are not validated. YOU need to validate before committing the change
Automate the setup of new devices. A DHCP server provides the location of a device software image and configuration file. If the DHCP server is not configured, the switch boots with pre-installed software and default configuration.
XML is a W3C standard. Junos OS uses XML for on-box and off-box automation. Multiple tools are available to possess, create, and display XML. XML uses tags like HTML. Data is placed between opening and closing tags.
XML Namespace XML namespaces ensure that element names and values are unique
XSD and XML files Here is an example XML in the Junos OS CLI uses the XML API to communicate with Junos OS infrastructure.
The Junos OS XML API responds to CLI queries with an XML document. The Junos OS CLI converts the XML response to CLI output: Juniper publishes an XSD document for every Junos OS software release. It can be retrieved from a Junos OS device using NETCONF or available as a free download. Navigating XML Using XPath Because XML is applied in a wide range of use cases, XML defines a document object model (DOM) to ensure XML documents are parsed consistently. XML Element Node (important ) An element node consists of matching opening and closing tags and any included data An XML document can only contain one root element