DevOps Intro for Developers: Part I
DevOps Intro for Developers: Part I
I've found that people are either not aware of basic concepts or are confused because of abundant information available online. I want to concisely simplify networking.
Join the DZone community and get the full member experience.Join For Free
Discover how you can reduce your Kubernetes installation from 22 steps to 1.
II’ve been working on setting up a couple of host and guest machines at my home and office for the last couple of years. I wanted to replicate real-world scenarios where we have multiple hosts on multiple subnets that still interact with each other. While working on this, I found that a lot of people are either not aware of basic concepts or are confused because of abundant information available online. I want to simplify networking in a short and concise manner.
I will also show application layers along with network layers to make it clearer. I see that these two departments don’t have any common knowledge in common everywhere in the industry. I would love my developers to understand network connectivity while designing distributed applications or even basic non-distributed applications.
There are 5 major components of that any company or network admin has to look at
and two basic concepts
- NIC cards (Network Interface Cards)
Gateway: This is the target appliance, device, or machine to which a source computer sends all of its packets for any networking (assuming there is only one network interface card in source computer). Note: a machine can have any number of interface cards as hardware supports. If we use Gateway, we mostly need to add static routes to all machines.
Firewall: This generally sits between cloud and internet and private network. It can control the flow of data packets from inside and outside interfaces (i.e., the Cisco ASA appliance). Without a Firewall, every network is susceptible to brute force attacks and heavy load on systems. (This link shows how everyone around the world is trying to attack each other digitally.)
Hub: This is a device to which all networking devices connect. This is good for lab testing, but not in the efficient way of connecting devices. A major disadvantage is that it broadcasts information sent from one device over a common channel that is visible to all other devices connected to that hub. This also creates unnecessary bandwidth issues as it floods information to everyone irrespective of who it is destined to.
Switch: This is an efficient way of creating a minimal network. Switches have multiple sockets to connect different available in networks. Switches separate communication channels between all devices, which makes it very efficient in connecting devices.
Router: As the name suggests, it routes traffic between different networks. This generally sits coupled with Gateway and knows where to send packets to. It stores all information in the routing table and decides the best possible route for any given packet. Router automatically takes care of routing removing need for nodes to add static routes
Below diagram explains a very high-level connection scenario:
If you observe in above diagram, I have one network with subnet 192.168.1.0/24 connected to one switch and the other network, 10.0.0.1/24, connected to a different switch.
Both of them are connected via a Router or Gateway, and Gateway is connected to internet via Firewall.
This explains a minimalistic design of any company.
We can have multiple layers of switches and Routers sitting on top of each other in tree fashion but the basic concepts remain the same.
Now for Network Interface Cards (NIC cards):
NIC: This is located in each and every networking device and enables the device to get connected via ethernet. These days, we can create virtual NIC cards on any operating system that behaves the same as a physical NIC. There are other concepts of NIC called NIC teaming or bonding, which improve the bandwidth and performance of Network IO apart from providing failover connectivity. I will explain all of these concepts in detail in subsequent series.
Subnet: Subnets are the single most important concept that allows us to segregate different kinds of networks. Originally, when networks originated in 80s, there was a concept of class-based networking (i.e., example: for 192.168.1.1).
Class A: the network portion is just 192 and rest 168.1.1 defines the node address.
Class B: 192.168 defines the network portion and rest 1.1 is the node address.
Class C:192.168.1 defines network and remaining 1 represents the node address.
This approach was good until the early 90's, but then the issue of IP address exhaustion started.
Then IETF introduced a concept of CIDR (classless internet domain routing). With the introduction of this approach, now the IP address is never complete without a network mask. Example 192.168.1.1 doesn’t represent a node unless we define the netmask. So now the IP address has to be defined as 192.168.1.1/2, where 24 represents 24 bits, which is a prefix or network portion of the above address.
With the advent of virtual machines and containerization of networks and operating systems like Linux, we can replicate all of the above devices with software code.
I will start by explaining each concept in detail and how to configure and build multiple computers and network routes in subsequent series.
Here are the technologies I’m going to use and topics I'm going to cover in the next couple of months. I’m going to write each one fresh using the latest version so that my code is not outdated.
- Vagrant (to manage virtual machines)
- Oracle VirtualBox (virtual machine provider; we can also use HyperV or VMWare)
- Docker (lightweight replica of VM, which can provide similar features)
- CentOS or Ubuntu (I’m going to use both flavors of Linux on different devices)
- Linux routing table for basic
- Quagga/Zebra to create a powerful router
- Iptables used as a simple Firewall
- OpenVPN to setup VPN connections
- Chef/Berkshelf (one of the most versatile OS provisioners)
- Shell Scripting (this is obvious)
- Apache or PHP or Mysql for a demo website
- Cassandra as a demo database to show how data gets across different racks in out virtual data centers (VMs on different networks)
I already have one base version written, which I’m going to reuse in bits and pieces.
Published at DZone with permission of Ashwin Rayaprolu , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.