# DevNet Associate (200-901)
## Contents
- Network Fundamentals
- Infrastructure: pieces, parts, protocols
- Network Automation
# Coding
## IDE
- Integrated Development Environment
1. Full-Featured IDE: Visual Studio, Eclipse, NetBeans, IntelliJ
(+) Feature rich, well supported, widely adopted
(+) Quick and easy, straightforward to use, Debug the code/Execute the file(if you have interpreter, plugin for the compiler) live in interface
(+) Create folders and files inside your project folder = portable. can move it to another system with all the settings intact
(+) Used as collaborative environment. Connect directly to source control & remote repository. ex. Git
(+) Fast, light, extensible(adding features like adding new app from app store)
(-) Tightly coupled(VSC-dotnet, NetBeans-Java), complex, can be bloated
2. Simple Text-Editor: NotePad++, SubLime Text, VIM
(+) Quick and easy to setup, extnesive usage, widely available
(-) Feature poor, Tedious configuration
3. Split the Difference: Atom, Brackets, Visual Studio Code(VSCode)
(+) extensible, plugin, designed for coders, easy to use
## VSCode
- Searchbar
- how?
- cmd+up+p(mac), ctrl+shift+p(windows)
- Custom theme
- >theme//Color theme
- Icon
- >theme//file icon theme
- Side bar
- >sidebar//Toggle Side Bar Position
- Toggle bar
- >breadcrumb//view: Toggle Breadcrumbs
- Icon
- >theme' > 'file icon theme'
- Settings
- how?
- comma+command
- Settings management from GUI to .json
- default//Workbench>Settings: Editor
- Font
- font
- Extension Gallery
- Similar to App Store.
- Installed in Users>.vscode>extensions
- search '@category: (themes/linters)'
*linter: 소스 코드를 분석하여 프로그램 오류, 버그, 스타일 오류, 의심스러운 구조체에 표시(flag)를 달아놓기 위한 도구
- Files, Folders, and Workspaces
- Workspace?
- Set that folder to a single Workspace
- You can have multiple Workspace Folder. Each workspace has a different root folder, so everything has separate settings. -> Workspace1 (root1, covers default settings of workspace1), Workspace2(root2, covers workspace2)
- Preferences
- User>Workspace>File
- User overrides Workspace and File, Workspace overrides File.
- Debugger
- Debug: eliminate errors in or malfunctions of debug a computer program
- Launch Debugging: Launch a file in VSC in debugging mode, and attached a debugger to it. Features - breakpoint, variables
- Attached Debugging: attaching to code that is already executing.
- You can debug your code even if it was not launched through VSC. ex. launched at web server, applications, CLI
- Every language have different debug options.
- Node.js option: --inspect-brk fib.js
- Python, C, C++, etc
## Basic Programming Control Flow
- Code Organizing Structures
- Goal: For people and computer, Structured and organized, Testable
- Control Flow Statements
- Control Flow Statements manage which code executes when, how often, and whether or not it repeats
- conditionals(If-Then-Else)
- loop(While, For)
- exception handling(Try): resilient to potential problems that happens during runtime
- Goto and Return(not really used now)
* Graceful degradation: the ability of a computer, machine, electronic system or network to maintain limited functionality even when a large portion of it has been destroyed or rendered inoperative.
- Control Flow Statements generally used in Imperative Programming Paradigm.
- Imperative Programming Process('How I want my code to execute') is decribed step-by-step. most of the programming languages.
- Java, Python, C, C#, JavaScript, Perl, Bash, PowerShell
- Declarative Programming Result('What I want') is described and process('How') is left to parser/interpreter/compiler
- Haskell, LISP, Erlang, SQL (SELECT * FROM * WHERE *)
- Conditional Statements
- Conditional Statements allow for different branches of code.
- Branches are exclusive.
- if (true):
- then;
- else:
- Branches can spawn additional branches. ex. nesting
- if:
- if:
- elseif:
- else:
- else:
- Overuse of conditionals, especially nesting, can result in poor code. Hard to read and maintain.
- Solutions include: Switch statements, Functions, and Object-Oriented Programming.
- Loops and Iteration
- Loops allow for code to be executed multiple times in succession.
- Many user-interaction portions of a program are based inside of a loop.
- Loops can be nested, and conditionals can be nested as well. ex. while>if-else
- Coding Principles
- DRY: Don't Repeat Yourself!
- KISS: Keep It Simple, Stupid
- The infinite loop
- ex. while True == True:
- Solution: Practice responsible looping, try tests
- Functions and Methods
- Functions allow for a block of code to be 'assigned to' a symbol and invoked on-demand.
- Code in function does not run until invoked(called).
- Functions can be invoked as many times as needed.
- We can pass parameter values to the functions so that we can make the function more abstract. It works differently everytime.
- ex. def revivePlayer(p): // p is a place for parameter
- revivePlayer(player1)
- Methods are functions defined as part of a class and invoked by instances of that class.
- Methods can reference the object instance they're being invoked from.
- Methods describe the 'behavior' of a class/object in OOP code.
- Object Oriented Programming
- An architectural style supported by many programming languages.
- The key is the use of 'objects' which are instances of a class.
- Objects in OOP can be created, destroyed, and manipulated in isolation from one another.
- Goal: Encapsulation, Isolation, Separation of Concerns
- Principle: Maintainable(easily fixed), debuggable(isolate bugs and fix), testable, legible(readable by others)
- Class State and Behavior
- Class = state(condition, variables, field) + behavior(execute inside the class)
```
class Circle:
ID = 0
radius = 0
def __init__(self, id,r): // This is called Constructor(생성자)
self.Id = id
self.radius = r
def circumference(self) // method
return 3.141*2*self.radius
```
## Design Patterns
- Design Patterns?
- An abstract patterns/guidelines. Ensure your program will accomplish what you wanted to accomplish.
- Applied in any language.
- Used in
- Tested solutions
- Framework/Scaffolding for new code
- Clarify intent/communication between developers
* Scaffolding? 데이터베이스를 이용한 프로그램에서 이를 기반으로 하는 MVC구조의 CRUD 프로그램의 뼈대를 만들어준다.
- Singleton Design Pattern
- Simple, straightforward
- A pattern that restricts classes to only being **instantiated once** during the execution of the program.
- Used in
- Database connection strings
- Configuration values (that loads up when you start the program)
- Constant/Static values
- Design
- A class with a private instance variable representing its only instance, a public getInstance() method to retrieve that object, and a constructor to enforce single-instantation
- Actual Code
Only the last line generates warning "Exception: This class is a singleton!"
- Observer Design Pattern
- A pattern where dependent objects(observer) are updated or notified by one or more subject objects
- A pattern that allows multiple different observers to receive updates/notifications when a single source, object, changes
- Used to
- Allow objects to react or respond in response to events
- Popular in UI systems. ex. update message when there is a graph update
- Two classes defined by observer pattern
v is variable, m is method
1. Subject
This maintains a list of observers and includes methods for attaching, detaching, and notifying observers
2. Observer
It has a method to receive updates from subject.
- Model View Controller
- Works in lots of web application
- A high-level abstraction where responsibilities are divided up into three loosely coupled components, Model, View, and Controller
- People can develop parallely in three components
1. Model - Stores data, represents devices
2. View - Displays data
3. Controller - Tells Model and View what to do. Logical flow, user interactions, and directs models and views. For example, receive events and directs models and views to perform.
## Git for Version Control
- Version Control Systems (VCS)
- Maintains a history of changes to files for reference and rollback
1. Centralized VCSs rely on a 'master' database or controller to maintain all data, history, file revisions, etc.
2. Git - Distributed Version Control System
- Every user has their own entire copy(clone) of entire repository. When you check in, your changes into the git is in local, not directly pushed out to the central server repository until you actually push it.
- Distributed VCSs allow for each 'node' to be a full clone of the entire historical record.
- (+) Not reliant on connection to centralized server.
- To create repository
1. Clone existing repository(URL): it will create local repository copy of that source code.
2. > git init // initializes empty repository
> git add (file): track/stage the file.
> git commit -m "Initial Commit" // commit all of the files that I have staged with 'git add' command
> git push // push the staged file to the central repository
- Staging and Commiting Files
- Files in Git follow a three-step lifecycle
1. Unmodified
(Make a change)
2. Modified
(Staging)
3. Staged
(Commit the staged file to repository then it becomes unmodified file)
1. Unmodified
- Rule
- Commits should be often and small. Commit is a lightweight operation.
- How to commit in local repository?
1. Make a change in code
2. >git add (file)
3. >git status // Should be in branch main, and have changes to be committed
4. >git commit -m "Message"
- You can also commit via VS Code
1. Make a change
2. Click '+' button in git mode = git add
3. Write a commit message & ctrl+Enter = git commit
- Viewing Repository History
- Git views code commits as a timeline.
- Blue reprsents commit, red represents modified state. Numbers below is hash value.
- This entire timeline is known as Branch-Master. Master means it is a default initial branch.
- head: where my next commit is going to go
- When you git commit
- To view repo history
- > git log
- > git log --oneline
- > git log --oneline -n 3 // only shows three logs that were newly made
- It will show all the logs in that repository in descending order
- Git Checkout and Detached Head
- Git Checkout changes your working directory to match a specific commmit.
- Timemachine. Any files that I made after that commit are going to temporarily gone from my folder, any changes that made to the files inside of my repository after that commit have been reverted back to the state they were at the point and time of that commit.
- > git checkout 0e33a50
- Red line is the detached head, black line is the main branch.
- > git checkout master // go back to the master brach
- All of the changes you made from the detached head state(checkout), regardless of they are commited or not, they're technically going to be lost. These are not resiliant or safe.
- Git Reset and Revert to Undo Changes
- > git commit --amend // replaces(overrides) the previous commit. Anything in your staging area will get added to the previous commit, and you will have to supply a new commit message. If there's nothing in your staging area, all you're doing is replacing the commit messge.
- 183F75D is off the branch, affectively removed. Orphaned commit. It technically is not removed but difficult to get it back because it is no longer associated with named branch. And it will be removed when git is doing a garbage collection.
- Recommendation: Only amend when you are working in the commit that only exists in your local repository. If not, it will create a conflict.
- > git reset HEAD~3 // removes commits, resetting the head points. Point the head back at the HEAD~3 commit.
- Three commits over there are orphaned. And the future commits will create new timeline.
- Only do on your local repository because if any of those commits exits in remote repository, there will be a conflict between local and remote repository.
- When you reset your head, none of your working code changes. The code remains as is, so the code will still look like your last commit, DD3905A, but the latest database repository is going to look like C89AEF3. So after reset you will have unstaged changes waiting inside of your git repository to be staged and applied to next commit. So if you immediately commit, you will make a new commit down in the main head point but will be look just like DD3905A.
- > git revert 183F75D// creates new commit that reverses the changes we made in the previous commit
- Preserving all history, it just reverses of that previous commit.
- How do you revert back multiple commands?
- Call reversion one by one. You cannot revert few steps in a single command, it will cause a conflict.
- Unstaging and Untracking Files
- Unstaging
- > git restore --staged (staged commit)
- Untracking files: '.gitignore' file
- How to remove a file that you accidently added to git?
- > git rm test.txt // Delete the file from both repository and file system.
- > git reset --hard HEAD // revert the previous step
- > git rm test.txt --cached // removed file from the entire repository, but leave it in the file system. It will become unstaged file after this command.
## Collaborate with Git
- Git clone, push, pull, fetch, merge, and remote
- Central Repository & local repository & team repository. But there's no set central repository, it's just you who dedicates the central and there's a convention of Github being a central.
- Every repository has its own self-contained, independent, source control unit.
- Initializing a repository with clone
- Git clone creates a local copy of a remote repository
- Clone from a local folder, SSH, HTTP, or 'Git(protocol)'
- > git remote -v // returns the given 'origin' that points to that original url I've clone from. easy words: memory of how I got this repository.
- Synchronizing with Remote Repositories
- Git push and pull allow commits from one repository to be synchronized into another repository.
- Origin repository: if you get git clone, you will have a origin repository
- Steps
- 1. git clone (url)
- 2. make a code change
- 3. git remote -v // to see your origin repository
- 4. git push origin
- Pull request
- You create pull request specifically staging your changes for that remote project and then the admin will review your changes and decide whether or not to pull/reject them into their repository.
- Goal: structure the synchronization so central administrator has control over what actually gets synchronization into their repository. particularly works in open sources.
- Working with Branches
- Git branch allows you to create parallel timelines that don't interfere with one another.
- A branch is like a nickname or alias for a timeline in the repository.
- So even when you push your commits up to github(central/branch repository) they still don't conflict each other.
- 'HEAD -> master' means head is pointed to the master.
- > git branch featureA // make a new branch called featureA
- > git checkout featureA // swtich head to feature A
- But, it does not resolves all merging problems(subbranch to main branch), simply gives you a way that you can work independently and worry about merging conflicts at future time.
- Merging Branches and Resolving Conflicts
- Git Merge combines two branches into a single timeline, consolidating their commit history.
- You get direct link you can traverse back on both branches.
- Target branch: The branch the changes are being pulled from
- Receiving branch: The branch the changes are being pulled into. Typically the 'current' branch in working directory(head)
- Conflicts in file changes must be resolved manually.
- Fast-Forward: No change in a master branch. Type of merge occurs when working in a bug fix.
=> git merge (branch name)
=> This command can merge branches if no changes were made in the same line of code and will interfere each other.
=> Result: All caught up in master and featureX branch and both are in one single timeline now.
- 3-Way Merge: Tips in the end of each branch and master = 3 way. There's almost no conflict you need to resolve. All commit history from both branches will maintain post merge.
=> git checkout master
=> git merge (branch name)
=> If conflict happens VScode will show which code you would like to choose. Only leave the code you want to use.
=> git add (file name)
=> git commit
## XML, JSON, and YAML Data Formats
- Why We Use Plain Text Data Formats
- Human Readable & Computer Readable
- Structured for computers
- Annotated for humans
- Open and Extensible
- Self-Describing
- Platform Agnostic/Lifespan
- XML, JSON, and YAML Data Formats
- XML: Extensible Markeup Language
- Tag describes data
- Similar with HTML
- Descriptive
- Legacy support: it's been around long time, and a lot of software supports XML to transfer data
- SOAP protocol: web based API protocol. Relies on XML to transfer its data and information
- (-) verbose. longer than other data formats
- (-) extra data, extra bandwidth
- JSON: JavaScript Object Notation
- Reflection of how you write objects inside JavaScript code.
- Javascript: popular. language of our internet browser.
- Lightweight: just { and ,s. No extra stuffs.
- Easy to read. But whitespace is not must. It's just for readable code. So JSON can shrink down compressed as small as possible.
- Native to JS: JSON is easy to incorporate with JS code.
- YAML: Ain't Markup Language
- Highly legible: best human readable
- Compact/Succinct
- Ideal for configuration
- XML Syntax
Well structured XML has four attributes.
1. Prolog: 'This is an XML document'
- <?xml version="1.0" encoding="UTF-8"?>
2. Root tag
- <People></People>
3. Tag syntax. Every tag must be opened and closed.
- <opening> data </closing>
4. Attributes are all set to equal value that is inside double quotes.
- Id = "2"
- XML Elements, Tags, and Attributes
- Element: Entire thing including both opening tag and closing tag.
- <Person Id="3"> </Person> is one element. It includes opening tag, attributes, and closing tags.
- <FirstName></FirstName> is another element.
- You can make an empty element. It can have attributes too. But cannot create any values as part of the element. Below are the examples.
- <EmptyElement/>
- <EmptyElement Id="17"/>
- Tag
- <Tag1> <Tag2> </Tag1> </Tag2> is not valid.
- <Tag1> <Tag2> </Tag2></Tag1> Tag1 is parent tag.
- You can use letters or numbers inside Tag name, it can be upper/lowercase. Just be consistant about it.
- Attributes
- name = "~" or '~'
- Here, Id="2" is an example.
- you can use &apos for ', " for " in attribute value.
- XML Document Object Model(DOM)
- Visualize XML like a tree and understand parent, child, and sibiling relationship between all nodes in your XML document.
- JSON Syntax
- Curly bracket {} represents JS object.
- {"key": "value"}
- all your keys should be inside double quotes "".
- Square bracket [] represents array.
- [object, object, object]
- myObj[0] to call whole first object
- myObj.People[1].LastName to call "Benjamin"
- JSON Strings, Numbers, and Booleans
```
myObj = {"People":
[
{
"Id": 1, // number, no ""
"FirstName": "Benjamin" // string
"Active": true // booleans(true, false)
}
]}
console.log(typeof myObj.People[1].Id) // typeof operator: show the type of particular value
```
- Output of the code> number
- JSON supports number, string, booleans, object and array.
- JSON does not support date, undefined values, functions as a value.
- JSON Objects and Arrays
- {,} in JSON: object. key-value. call by **.key**
- [,] in JSON: array. key is numeric index [0] ~ [#]. call by **Array[#]**
- subobject
```
- {
"Name": {"FN": "Jane", "LN": "Doe"}, // subobject
"Email": "jane.doe@cbtnuggets.come"
}
```
- YAML Syntax
- Indentation level: arbitrary but the level needs to be same within each other. It can be two blanks, three blanks or even more. Just keep it same with others in the single object.
- YAML: numeric(integer, floating point), string, boolean, list, array
- Scaler: '-' identifies a group of objects(mapping. key-value pair in JSON)
- Starts with '---'. Required.
- '...' at the end. Because YAML supports multiple documents inside single file.
- So for example,
```
---
code code code // 1st YAML document
...
---
code code code // 2nd YAML document
...
```
- Use '#' to start comment. YAML supports in-line comment.
- YAML Strings, Numbers, Floats, and Booleans
- key: value
- QuotedString supports escape character like '\n', '\' + unicode character.
- String is literal, not supports escape character. To enter the line, use whole blank line between strings.
- Booleans: true, True, TRUE
## Parse Data Formats into Python Structures
- Parsing Data Formats with Python
- Serialization: Create data from programming language, and pump that data out of the data format XML, JSON, YAML.
- Deserialization: Read data in.
- storing in plain text data XML, JSON, YAML.
- Parsing XML with Python
- sample.xml
- sample.py
- ET(ElementTree) Python built-in library. Easy way to parse and look through inside XML file.
- sample2.py - lxml
- lxml: Recommended. Extension of ET. Uses the same object types(xml, root, e) as Element Tree library, but it's a custom library that's faster, cleans up edge cases in XML
- sample3.py - xmltodict
- xmltodict: reads your XML file into ordered dictionary object inside of Python. similar to JSON.
- XML Libraries in Action
- choose between xmltodict and lxml in your comfort level and your use cases.
1. xmltodict import
- key codes
```
netconf_filter // xml filter
interface_netconf = m.get(netconf_filter)
# XMLTODICT converted xml output to a python dictionary
interface_python = xmltodict.parse(interface_netconf.xml)["rpc-reply"]["data"]
```
2. lxml import
```
data = interface_netconf.data_ele // lxml element. This inteface responds with both raw xml and the xml property(in python) as well as the element(data_ele) that allows us to brought right into lxml
```
- To call the data inside lxml
- 1. data[0][0][0]. Easy but if you know what node or what index you're going to have, but if order changes between properties there will be a problem.
- 2. data.xpath('.//nc'): look up the name value out of this document.
- Parsing JSON with Python
- 'json' is a built-in library in Python.
1. loaded JSON out of string
2. loaded JSON out of file
- Mapping between JSON and Python data structures
- JSON object == Python dictionary
- JSON arry == Python list
## Parsing YAML with Python
- Translate YAML document into Python object.
- Need to insall pyyaml library, easily load your YAML documents even when multiple documents inside of a single file, and bring them into native Python structure.
- sample.yaml
- Three dictionary people, first, second. People is a key, and value for people is list(array of objects), and one of those is associated with arrays.
- yamlsample.py
- loader= Fullloader, Safeloader(ideal for yaml code from unknown or public location. Ensures you don't load any invalid character, injection and tags from code.)
- load: load one document
- load_all: load all YAML document
## REST API Fundamentals
- Introduction to RESTful APIs
- API: Application Programming Interface
- A way for a computer program to communicate directly with another computer program.
- RESEful API
- An API that follows a specific set of constraints. Often used online over the https protocol, and payload is JSON data usually(could be XML or any data).
- RESTful API Constraints
- Uniform Interface
- API follow a consistent and decoupled interface for API calls.
- Ideally only onoe URI for any given resource.
- ex. /movies/{movieId}
- ex. /movies/{movieId}/update
- ex. /movies/{movieId}/delete
- Client-Server
- There must be a decoupled(independent) client and server in the implementation architecture.
- All communication happens between the API interface.
- Stateless
- Each API call must contain everything needed to perform the requested operation.
- Every API is independent.
- Ther server cannot remember the client from request to request.
- (Layered)
- (Cacheable)
- (Code on Demand)
- REST vs. SOAP
- Both REST and SOAP are approaches to build an API for inter-program communication and passing data and commands back and forth.
- REST: Represenatational State Transfer
- Guidelines for the structure and organization of an API.
- 99.99% RESTful APIs operate on http protocol.
- Not a protocol. It's an architecture 'how the code is organized'. It tells you where your components should be in the overall hierarchy of your communication, but it doesn't tell you what communication platform you should use, or what messaging protocol you should use, what data format you should use.
- Can use JSON, XML, YAML, markdown, CSV, plain text.
- Light touch. Used in public API, environment that doesn't have a lot of computing infrastructre resources.
- (Query) RESTful APIs can use querystring or request body.
- ex. https://mycoolapi.com/employees/list**?dept=17&active=true** <- Querystring: pass parameters up to your list function inside of the URL self.
- ex2. Request body as part of the payload of http request.
```
{
"dept": "17",
"active": "true"
}
```
- SOAP: Simple Object Access Protocol
- A protocol - Specifications at various layers including message transmission, data format, and security.
- More overhead, but more comprehensive.
- Only uses XML.
- Used in enterprise enviornment, internal network communications between large enterprise driven systems, where security is the most importance.
- (Query) SOAP requires a verbose XML document.
- ex. Header, body, message block
- Query have to be formatted and structured in the specific document.
- Your endpoint hits base url 'https://mycooolapi.com' and everything you want to do need be included in SOAP document.
- REST Tools
- To generate the request, visibilitiy of what's happening behind http request
1. Devloper tool in Chrome
2. REST Client in VSCode: protocol, response code(200 OK), headers in response, JSON response from API
3. Postman: Graphical user interface tool to build APIs. You can see raw request, query parameters, response, cookie, response headers.
## REST API Requests and Responses
- HTTP Requests and Responses
- You type the web address -> Hit enter -> Your web browser creates http request with your web address -> response back on web page
- Response can be web page, API response, or error message.
- All HTTP/1.1 requests and responses are plain-text formatted communications that follow a specific structure
- Two ways to see raw API request and response codes
- Web browser -> Developer's tool
- Postman
- Start line: information of type of request
- Headers: key-value pairs(strings) that you are passing up to the web server in a request, or the web server is returning back to you in an response. Technically optional but almost every request have few headers associated with it.
- Blank line: we're done with the upper portion of the request.
- Body: payload data. Optional.
- Google -> developer's tool ->
- 
- 
- raw plain text of http request
- Start line - GET: verb, HTTP/1.1: protocol
- Header - line 2~11
- Blank line - line 12
- Body - line 13. No body in upper one, actually there might be no body in requests. Below picture has a body which is in {}.
- 
- Raw data of resopnse
- Start line - HTTP/1.0: protocol, 400 Bad Request: response code with text of it
- Header - Content-Type to Date
- Blank Line
- Body - body of the response. HTML here.
- Purpose of viewing raw API data: Insight of what's going on behind inside your web browser, Check you're sending a right data in the right format, at right time, and review/inspect when you're not getting the response that you expected.
- HTTP Request Method
- Method = Verb
- The HTTP request method is a single word 'token' that loosely describes the desired action being performed. Instructions you're giving to web server.
- Verb is in the start line of API.
- There are various methods
- *GET*: to look up information.
- HEAD
- *POST*: update. to send information and change a given record. NOT Idempotent.
- UPDATE:
- PUT: update but Idempotent. So if you send retry a request multiple times, that should be equivalent to single request modification.
- DELETE
- CONNECT
- OPTIONS
- TRACE
- Purpose of Verb: You need to know the endpoint of URL, what verb are you expected/allowed to send up to that endpoint. The same endpoint may support both GET and POST at the same time.
- HTTP Response Codes
- Every HTTP response has a 3-digit numeric code indicationg the type of response.
- Typically a text note is included with the code. Ex. HTTP/1.1 200 OK <- OK here.
- The codes are catagorized based on the first digit:
- 1xx: Informational Responses
- 2XX: Successful Responses, 200-OK
- 3XX: Redirects
- 4xx: Current Errors
- 401-Unauthorized: user has not even signed in)
- 403-Forbidden: user is not allowed to do what they're doing
- 404-Not Found
- 5xx: Server Errors
- These codes are standardized verison of response codes. But developer can return any code they wanted. Below are the examples.
- Text is '404 Error' instead of '404 Not Found' standard.
- HTTP response code: information about what has happened with the request you've send up to the server alongside of any additional code they want to send.
- HTTP Headers
- Headers are key-value pairs that are sent up to server with your request, and turn, sent back down to the client with the response.
- Each request and response has different headers.
- No rules of which headers should be included, but there are few popular headers.
- Optional in either request or response.
- General Header
- Request/response headers
- Upper API is request, below is response.
- Made up by the server. They may or may not mean anything to my browser. The serever may interpret or ignore them. There are no hard rules about how these things work.
- Key-values are conventional, but not necessarily by any rules.
- The headers are not meant to send actual data to the server or back. It's meant to send additional data about the request itself.
- ex. gzip - upgzip it before the web displays it.
- host- host you're sending a request to. So if server is serving up more than one host(web page), it'll know who that request was intended for.
## Parameters and Payloads for REST APIs
- Purpose of Parameters & Payloads: To transmit data alongside with the request inside the API body part.
- You can plug it inside URI as well.
- HTTP Query Strings(Parameters)
- Key-value pairs inside request URL.
- Base host: 127.0.0.1
- Port: 5500
- Target: formtarget?
- Query string: ?name=Ben&addr=1234+River+Road
- form: always at the end of URL, starts with ?, key=value & key=value & key=value.
- key are name and addr.
- value are Ben and 1234 River Road.
- method="GET"
- because of GET method inside the form, the values of my form are built into the query string and added into the URL. So you can use this querystring to transmit value/data in key-value form up to the remote server.
- method="POST"
- Put values inside the payload.
- Using HTTP verb?
- Subit -> Browser creates HTTP request, it uses this form method to decide which method type should be at the beginning of that http request.
- Query string vs. Payload
- Query String: By includind these data to the URL, you can cut and paste these query strings to anyone. When others paste it, they would be generating the exact request as you.
- Payload: hidden, obscure from you.
- Why use the Qurery string instead of headers? They are both key-value pairs.
- Headers are not included in URL so you can't cut and paste the headers into another form to transmit those. ex. search parameters
- Headers are intended to transmit data about the request, not the data the request they're actually transmitting.
- Etc.
- Query string should be short, quick values, often associated with the GET(or POST or PUT but not usually)
- HTTP Payloads(Body)
- Data attached to the HTTP message. It can be HTML format, JSON format or others.
- ex. Image data, form data, HTML page, music files, video.
- Purpose: Store and transmit a large chuncks of data between server and client.
- Query Strings and Payloads in Action
- *resource_url*
- Hypertext as the engine of application state
- Your JSON responses in RESTful API often includes links and these links tell you how you can navigate through rest of the data.
- Purpose: I don't need to rely on documentation. Once I get into an initial internal endpoint, smart API will give links in helps to navigate the rest of the APIs.
- Summary
- Request API has querystrings, payloads.
- Response API doesn't have query strings but it has payloads which is associated with the message.
- Payload: API want to respond you with. Typically JSON or HTML. Big chuncks of data.
## Authentication with HTTP and REST
- Introduction
- Most APIs will require some sort of authentication and authorization in order to be used.
- Authentication - Prove who you are who you say you are.
- Authorization - Prove you are allowed to do whatever it is you're trying to do.
- Base64 Encoding vs. Encryption
- Differentiate *data* to transmit and *command* for our system.
- Encoding
- Encoding is not encryption
- Encoding allows us to transmit binary data over systems that use text-based control.
- Encoding is reversible by design.
- Another way to write the same information just using limited character set(base 64: 64 char available to use)
- Base 64 Encoding uses 64 characters to represent data and is considered 'URL safe': not includes command and control characters that HTTP relies upon so we can transmit any binary data over HTTP as long as it been encoded first
- Encryption
- To obscure our data.
- Modern HTTP uses the TLS protocol to encrypt data in transit. TLS is successor of SSL encryption and they are interchangeable but now SSL is deprecated in favor of TLS.
- When TLS is applied to HTTP it's known as *HTTPS*
- Encryption is also reversible, but only for the person in possession of the 'private key'.
- It is safe from any outside interference but if either system in the end of it is compromised, the encryption doesn't matter. So still have to trust the system you're sending that data to.
- HTTP Basic Authentication
- One of the most straightforward and oldest way to do authentication over web.
- Basic authentication is described in RFC 7617 == Prescribed, well-documented HTTP protocol
- Plain-text username and password are collected from a user and transmitted to the server in a request header. So always use HTTPS to ecrypt username and password when you're using basic authentication.
- Server verifies(Authentication) and decides what you can do(Authorization).
- 
- In the Header key-value send 'Authentication-Basic username:password(in Base64 encoding)'
- You need to remember your crendentials. Server is not remembering that you signed in with that username and password on subsequent calls who you are.
- So client retain those credentials in local session storage and retransmit those in the header with every single request. However, this should be done only in secure system. If you're worried about local system being compromized, you have to do it over HTTPS so that it's TLS enrcypted.
- HTTP API Keys
- Basic authentication relies on username and password and *user* would remember those credentials and key into the systems.
- API Keys: Single token. Stored inside application so *app/program* can access API resorce opposed to a person.
- API keys are similar to Basic HTTP Auth.
- Plain-text token is generated, stored in a program and transmitted to the server in a request header.
- Token: Base64 encoded copy of that token generated for you.
- API keys will typically be used to grant full administrative access to system so you don't use it often.
- So API keys to give basic, inital access to the storage account, but you're expected to create user account to have narrow scope and limited access to that account.
- ex. Cloud based storage application: Azure
- 
- Access API keys are the credentials.
- Two keys?
- To recycle keys for security. Migrate software to key2 when you want to update key1 without break software.
- Token Authentication
- Most popular form of authentication.
- Allows us to create stateless authentication methods, and allows us to have a lot of control over the claims/data that we're associating with our user requests.
- Token-based authentication is the most popular form on the web today.
- JavaScript Web Tokens(JWTs) are the most popular form of token used in web auth today.
- 
- Cryptographic Signature: Signs JSON data
- User signs into website, and in return they get JWT. They send back the JWT with every subsequent requests they made to the server.
- {JSON} = {"userId": "12345"}
- Cryptographic Signature
- A way server take some data and send it back to you but include hashed encrypted version of that data along with that data.
1. Both original data(JSON) and and signiture need to be sent back to the server everytime.
2. Then server look at the signature and compare it to the data and verify that the data is unchanged. If the signature and data doesn't match, server will reject the JWT.
- {JWT} = eyJhbGc~~ // Base64 encoded
- Why do we use JWT?
- Before: not stateless, not RESTful. Server needs to go back to the database everytime.
- Session Id: Attached to client computer.
1. Server remembers Session Id of the user and stores identification of user back such as local database.
2. Everytime user subsequently goes to the website and tries to perform operations, the Session Id is sent along with those request
3. Server goes back to the database and looks up the user information
- JWT: Stateless
1. Server hands back the JWT.
2. User passes that JWT each time.
3. Server does not have to go back to database.
- Benefits of JWT
1. Speed - Server doesn't have to hit storage/DB for each user request
2. Scalability - You can safely distribute/balance requests across many servers.
- Pushback against using Token for stateless requests
- Technically not the most secure way to use.
# Use Postman for REST API interaction
## Introduction
- Postman: GUI runs on your local PC and you can use to invoke API calls.
- Postman will save the request you've build up in the cloud and you can access them in any device.
- Postman Echo: publically available Postman service. You can test the structure form of your API request.
## Postman Requests and Responses
- postman-echo.com - URL. endpoint for API.
- https// - you can leave out. Postman will add it for you.
- GET - verb
- When you fill up key-value in user interface below, it will be added to query string. It works reversable too.
- Headers: works just like query parameters but just put it in 'Headers' tab.
- Postman Console: actual log of everything you've been doing in the session.
- Highlighted line is a header tab.
- Body
- none
- form-data: simulate the act of filling out html form. So when you fill out html form, you have a submit button that post/gets data up into your API, it gets added as the body under your URL.
- Request Body in the picture.
- x-www-form-urlencoded: same as a querystring but it puts it in the body.
- 
- When you fill out the body(with x-www-~) and request it in postman, it automatically fills in the Content-Type Header for you.
- raw: text(Text, JSON, etc.). The header Content-Type is changed to application/json.
- It's appropriate standard for sending up request when your body has a specific content type in it. A lot of servers expect Content-Type header to be filled in so it knows what to expect inside of the body.
- Responses: Body(actual JSON data sent back), status, time, size of the response/Headers(Content-Type)/Cookies
- Highlighted part is a response header and below is a response body.
- Save button: click this and now request details(API, custom header, body, query string) are saved inside my Postman account.
## HTTP Auth with Postman
```
https://postman-echo.com/basic-auth
```
- Auth type: Basic Auth
- Response
- Adds this value to request headers' Authorization for credentials.
- Highligted part is a Base64 encrypted version of username and password. Postman was able to fill out that header for me to do authentication.
- Auth type: Inherit auth from parent.
- 
- 
- Collection>Edit>Authorization>Type: Basic Auth & Username and Password
- Collection: save your authentication to the higher level and apply to multiple requests, if you need to at one time.
- So even though I don't have any authorization stored with it, when I send it I still get {"authenticated": true} because it inhereted that details from the folder.
- Benefit
- Can have multiple different endpoints/request inside the folder.
- Instead of copying username and password over and over again, I can just store that information with the collection and reuse it. Also, if I want to make a change, I just need to change once.
- Auth type: No Auth
- Override the choice from the collection header(which we choosed from Inherit auth)
- Auth type: API key
- Override with own local choice when other requests in the collection will use Inherit auth.
## Postman Collections and Folders
- Collections: A list of API request you've pre-built and pre-configured that are associated with one another.
- Ex. API requests calling the same endpoint, Share authentication schemes so you work with them together.
- Subfolder Authentication
- Collection > Subfolder
- Subfolder can have authorization scheme associated with it too.
- Collection>Add folder>Sub Folder
- Run entire folder once.
- Test > Run > Run test
- Run every request inside of the folder.
- Result
## Postman Scripts
- Postman runs a *Javascript environment* for script execution both pre- and post- request.
1. Pre-request scripts
2. Test scripts
- Run test against the results in the side of response and validate whether you got results that were expected.
- Order: Scripts associated with Collection-folder/subfolder-Request-Request runs-Respose back- [NOT IN REVERSE ORDER] Collection-Folder-Request scripts.
- All below has Pre-request Scipt tab and Tests script together.
- Pre-request Script Tab
- You can see log first and my script run below that.
- Folder Script: Folder>Edit folder>Pre-request Script
- Collection: Collection>Edit collection>Pre-request Script
- 1-1. Pre-request script: Set environment variable
- Call timestamp in pre-request then you can populate it in actual script.
- Result
- Test scripts example
- FAIL because I didn't get 200 but 404 because this endpoint only allows GET.
- You can validate status, data inside JSON or HTML etc. in Test scripts.
## Postman Environments
- A way to create groups of variables(key-value pairs) that you can use inside the request and you can quickly switch between them.
- Created two varibales inside environment.
- To use varibales from environment, {{variableName}}
- I can change value to test out different values inside of the variables but still have initial value.
- Use URL as variables
- Variables stored in environment can be used throughout my requests in order to populate static values that change as I change by each environment.
- Variables can be used in code, including pre-request script and test script.
## 16. Network Programmability and Automation Foundations
### Why Network Automation?
1. Faster
- deployment, collectoring and monitoring info, troubleshooting.
- Agile: 프로젝트의 생명주기동안 반복적인 개발을 촉진
2. Standardization
- Snowflaked environment
3. Known Outcomes
- You know what this code will do, what outcome it will bring out
- Less human error
- Scalable
4. Monitoring
- Collect specific data as quickly as reqested.
- Configuring, bandwidth, QoS
- Can make an integration
### NetDevOps
- See each of our device as object. -> object oriented programming: Python, Powershell
- Deploy end-to-end application by NetDevOps
### Types of Automation
1. Monitoring: Read only
- SNMP(simple network monitoring protocol)
- Traditional monitoring protocol
- Not targeted data: You'll get more/less data. It's all or nothing.
- Now
- Pull out the specific data I want
2. Provisioning
- Previously
- Same base config in multiple devices: username/password, AAA/TACACS, OSPF Advertisement
- Repetitive task
- Now
- Jinja: Python Templating file
```
hostname {{device.hostname}}
domain-name {{device.domain}}
- YAML: Device config file
```
--device
- hostname: myhost
- domain: mydomain
```
- Template(with placeholder): Series of YAML file on multiple devices, with just one template.
3. Migrations
- Cisco -> Cisco/other vendors
- Generate Template, configs
- Generated config from what I've got, then generate template from new device, combine those two.
4. Config Management
- config devices
- Managing the state of our confiurations.
- Desired state for our network
- Drift from it. Correct itself, or alerting us so that we can corret them.
- Implement policies.
- ex. Never use VLAN 21 (policy check script) -> alert policy violation
- Security compliance
5. Troubleshooting
- Get specific data rather than go through everything.
- ex. Check all OSPF adjecencies -> Report back anything abnormal(that you determined in script)
- For example,
- Self heal the network. 10mbps down, 2mbps: ACL that blocks non-priority traffic and only forwards priority traffic.
- Policy based routing
- Benefit: Troubleshoot without critical outage.
### Network APIs
- Human -> Computer Interact with device
- Machines communicate using APIs. Pass data back and forth.
- Network devices communicate using APIs
- Past: SNMP
- 20+ years ago
- Agent collect data in device -(NMS, Network Management Station)-> Report back
- Cons
- Data is vendor specific.
- All data or none.
- Couldn't build logic around data. Cannot build your own application around it.
- Needed reactive script
- Not very secure. SNMPv3: handshake isn't encrypted/authentication
- UDP. Not guaranteed protcol.
- Past/Present: CLI
- Not dead.
- Basically useless for network automation.
- Two protcol
1. Telnet: sent in clear text
2. SSH: encrypted
ex. PuTTY
- Type in Host name(or IP address), Port, connections -> connection created
- Present/Future: Netconf
- since 2006 by IETF
- Network Configuration
- Works with YANG
- Replace SNMP which is vendor specific
- Sends data to and from using XML, structure data format.
- Server(network device) <-> Client(computer)
- Netconf transports data through SSH, port 22.
- SSH uses TCP.
- RPC(Remote Procedure Calls)
- Pre-programmed commands to perform pre-programmed operations
- ex. get-config: get the running config (in any vendor device)
- Get back in XML format.
- RESTCONF
- Netconf protocol to use with REST API
- Rather than using get-config RPC command, we can send HTTP GET request and specify the place with URL endpoint '/interface/gigabit ethernet'.
- Simply, use REST API(HTTP/HTTPS GET) and REST endpoints to use Netconf.
### Network Programmability vs. Network Automation
- Programmability: writing scripts to perform specific tasks on specific devices
- Automation: Broader. Repeatable task against large number of devices. ex. entire Data Center
- Desired state
- Application is accessible by public internet port:8080. We want software to handle VLANs, trunking, firewall rules. We just say desired state is the app is accessible through 8080.
- Intent Based Networking
- Self healing
- 
- Ansible
1. Automation(what we want to happen) and Orchestration tool(when, on what order we want to happen)
- ex. What: set an ip address in loopback interface, when: after we validated loopback interface exists. If not, create it.
- Ansible: Check first to see if it needs to run this process before it takes an action.
- ex. If we have loopback address, it will pass
2. Python
- Translate and send these commands to network devices.
3. Free, open source, cross platform
4. Agentless
- You don't need to deploy Agent to work. Salt, Chef, Puppet requires agent.
5. Modules
- Playbook (in YAML): Automation and Orchestration
- Module: pre-built set of instructions that Ansible already knows how to translate from YAML into full Python script
- 1000s of pre-built network programmability commands in it. All you need to do is specify modules and provide couple inputs.
- **Ansible -> Translate into Python -> Exectues it** against the devices you specified or which are relevant.
### Devices and Controllers in the Era of SDN
- Python script in all swiches, script in controller machine.
- Data plane: data actually transmitted from one devices to another
- Control plane: decision where to send a data.
- SDN
- Intent: 8080 needs to be accessible by 10.110.0.20 for Tenet A.
- Cisco: several different controller(DC: ACI-runs on a server called APIC)
- DNA: control & manage network. IPAM server: network addressing, historical network logging information.
- So we want IPAM to integrate with APIC environment. We can control how IP addresses can handed out.
- DNA Center sits on top of ACI, provides great API interfaces for us interact.
## 17. Prepare a DevNet Study Environment
## Installation Checklist
- Ubuntu 18.04 Desktop
- Python 3, 2.7
- Git CLI
- VS Code Editor
- PIP: Installs commands and libraries for Python.
- c-client: connect to NETCONF devices
- requests: connect RESTCONF devices through HTTP
- pprint: pretty print
- xmltodict: Convert xml strings/queries to python dictionaries
### Sandbox
- Cisco DevNet Sandbox Labs
- You can connect to network devices, lab, and tear down when it's done.
### VIRL
- Not buying networking devices or licensings to develop.
- But I want to test my development.
- VIRL: Virtual Network emulator
- 
- Purchase VIRL
- Hypervisor(Dell R710 ESXi, VMware Fusion, VMware Workstation) running on VIRL - OVA(Open Virtual Appliance) virtualization template
- VSwitch
- VM: Ubuntu
- NIC 1: Go out to public internet
- NIC 2: Connect to vSwitches
- VIRL template with 5 NICs: decent amount of horsepower requried.
- 5 NICs go into separate VLANs. ESXi calls it 'port groups'. Template will go the detail for you.
- First NIC is going for VM network and that needs to go out for actual router and Internet. VIRL server check-in and get license, updates.
- Rest NICs are used for your lab topology.
- VIRL is a Hypervisor too, for VIRL VMs on top of it.
- VIRL VMs: VM NX-OS, CSR 1000 router, ASA. In the lab VMs will talk to each other.
- To connect Ubuntu VM with VIRL VM: Second NIC bridges out to vSwitch and Ubuntu VM can connect into the vSWitch too.
- You'll code on Ubuntu VM and it'll connect into VIRL VMs(network devices) for development.
- Second NIC can go out to the Internet too.
- To buy VIRL
- Cisco Learning Network Store -> VIRL + Cisco software images on it (DC switches, DC routers, adaptive security appliances) in $199
- Some of the images of virtual machine(CSR 1000v router devices) doesn't come with all the features you need in order to configure NETCONF and RESTCONF(remote management feature set).
- (*) You have to download different version of that images. Search 'CSR1000v'-> Select the right version that support the additional feature you need
- Use VIRL
- Go to the VIRL server with VM you're going to use(Ubuntu)
- Download VMMaestro to build your lab.
- Node resources -> Images -> Upload your image by 'Add' -> 'Subtype: CSR1000v', 'Image File: Local image file, (*)' -> Save
- Your VIRL server is ready for DevNet Environment!
- VM Maestro
- Tool to build topology
- Two Nexus Devices connect to flat-1(physical, external network for production). Ubuntu VM comes in through flat-1 into Nexus devices and it goes on to other network devices(CSR1000v).
- To configure NETCONF and RESTCONF on the devices, you have to enable those features through command line.
### The DevNet Code Exchange
- Cisco public code repository: CodeExchange
- Programmability
- Automation Exchange
- Ansible, Salt, Puppet
- Three categories of skill level
- Walk: new to Automation
- Run: intermediate level
- Fly: expert at automation
Sign in with Wallet
Connect another wallet