0:00 Hey everyone, Brandon Lee from
0:01 Virtualization HowTo. And let's be
0:03 honest, documentation is one of those
0:05 things that most of us hate doing. But
0:07 if you're running a home lab, whether
0:09 it's one mini PC or a full-blown rack of
0:13 gear, documenting everything the right
0:15 way is a total gamecher. And I'm going
0:18 to show you just how to do it and what
0:21 tools that can make your life easier.
0:23 So, let's jump right in.
0:26 [Music]
0:35 Let's start with why documenting your
0:37 home lab matters. Isn't it just a lab
0:40 environment? If your lab is constantly
0:41 changing, and let's face it, they are.
0:44 If yours is like mine, it's in constant
0:46 state of flux. Documentation is more
0:48 important because of that fact. Now,
0:51 here's what solid documentation though
0:53 gives you. First, it helps you with
0:55 troubleshooting. You can retrace your
0:57 steps when something breaks. Second, it
1:00 makes it much easier to reproduce those
1:03 setups. It also reinforces your
1:05 learning. Writing things down just makes
1:08 it stick. Fourth, it surfaces patterns
1:11 that you can then use to effectively
1:14 create automation. And lastly, it gives
1:16 you practice with compliance style
1:18 habits that you're going to need in
1:21 today's production environments. Now,
1:23 where do you even start? Well, the
1:24 answer is simple. Start with an
1:27 inventory. List all of your components,
1:29 both hardware and software. Now, what
1:32 are some things that make sense to
1:34 track? Well, track things like host
1:36 names, IP addresses, MAC addresses,
1:39 make, model, serial numbers, firmware,
1:42 BIOS, drivers, OS versions, and services
1:46 that you have running, and even physical
1:48 location. If you got multiple rooms or
1:51 racks, simple tools like Google Sheets
1:53 or Excel work. But if you want to level
1:56 up, tools like PHP IPAM and Netbox make
1:59 this much, much easier. I personally use
2:01 PHP IPAM to track things like IP
2:04 addresses, VLANs, MAC addresses, and all
2:08 of those really detailed things that we
2:10 like to have when we need to remember
2:12 something about our network
2:13 configuration. Now, also if you're a
2:15 visual thinker like me and visual
2:18 learner, diagrams are gold. As your
2:21 environment evolves, a good diagram
2:23 helps you to recall how and why
2:26 everything is wired up the way that it
2:28 is. Now, here's some great free tools to
2:30 note. There are tools like
2:33 draw.io or aka diagrams.net, net
2:36 excaladraw which you can even self-host
2:39 lucid chart which even though it's an
2:41 enterprise tool has a polished free tier
2:44 then there's tools like obsidian canvas
2:46 if you're already an obsidian user and
2:49 of course there's the old school
2:50 Microsoft visio use diagrams to document
2:53 network topologies things like LAN WAN
2:56 and your VLANs VM to host mappings app
2:59 dependencies NAS storage and your
3:02 fileshare layouts configuration files
3:04 are the heart of really all of your lab
3:07 environments and how they work
3:09 correctly, especially if you've gotten
3:10 into things like Docker containers.
3:13 Don't lose track of your configs. Use
3:15 something like Git and private repos on
3:17 GitHub, GitLab, or even Git T if you're
3:21 into self-hosting those solutions. I
3:24 store things like pfSense and opensense
3:26 firewall rules, Docker Compose files,
3:28 Kubernetes manifests, Ansible playbooks,
3:31 Proxmox VM configs, and a tool like VS
3:34 Code is a great front-end editor for all
3:36 of this with built-in git support. Now,
3:39 also a HomeLab wiki becomes your second
3:41 brain. All of those one-off fixes and
3:44 unique setups, you need a way to have
3:46 those written down and to potentially be
3:48 able to surface those wherever you are.
3:50 Now, here are great tools to use for
3:53 something like that. There are tools
3:54 like wiki.js, which is a modern
3:57 markdownbased wiki tool. There's
3:59 bookstack, which is a clean UI and easy
4:01 to use. Docuiki, Obsidian, Hedgeoc,
4:04 Gitbook, and something like Gitbook is a
4:07 commercial tool, but again, it has a
4:09 free tier for a single user. Now, what
4:12 should go into this documentation? Well,
4:15 certainly you can write things like
4:16 how-to guides, troubleshooting steps, OS
4:18 install notes, container configs,
4:20 upgrade logs, and really anything else
4:23 that burned an hour of your time trying
4:25 to figure out. Don't burn that hour 6
4:28 months down the road. Again, pull out
4:31 your documentation and save yourself all
4:33 of that time wasted reinventing the
4:35 wheel. Now, your network will get messy
4:38 fast. Trust me, documenting your network
4:40 early is the key to having successful
4:43 documentation. And key details that I
4:45 like to include are things like VLAN
4:46 IDs, what they're used for, subnets,
4:48 reserved ranges, DHCP scopes, static
4:51 IPs, firewall and NAT rules, Wi-Fi
4:54 SSIDs, and passwords. All of those
4:57 things, you think you know it at the
4:59 moment, but again, 6 months later. Also,
5:01 helpful tools include things like the
5:04 UniFi controller. It comes with a
5:05 built-in topology mapper. Uh also tools
5:08 like Netbox again super helpful for
5:11 network mapping and documentation and
5:13 also open source security tools like
5:15 Inmap allow you to run regular scans to
5:18 detect devices or rogue machines. I also
5:20 use Arpwatch and definitely look at some
5:23 of my material on spinning up your own
5:25 ARPwatch container. I think that is a
5:27 fantastic tool to run not only in a home
5:30 lab but in a production environment for
5:32 security purposes and documentation.
5:34 Also, automation creates its own
5:36 documentation. So, especially if you're
5:38 using infrastructure as code tools like
5:41 the well-known tools that we're all used
5:43 to and familiar with and have grown to
5:45 love, such as Terraform for our
5:48 declarative infrastructure creation of
5:50 that infrastructure, Antible for config
5:53 management, tools like Packer that allow
5:55 you to build out your VM images. So when
5:58 you write your code and learn to store
6:01 that code in a Git repository and add a
6:04 readme file, it's like writing
6:06 documentation that basically runs
6:08 itself. You've got everything documented
6:10 and you know what everything does and
6:14 it's very transparent. But what if your
6:16 lab goes down? Backups do matter. Keep
6:19 secondary copies of all of your
6:22 documentation and things like cloud
6:23 storage, a cloud drive, Dropbox, S3
6:26 storage, any of that type of storage in
6:28 the cloud. Also, external drives may be
6:30 a good solution if you want something
6:32 cheap and you've already got the
6:34 external storage. You can use external
6:36 drives with Rustic or Borg. You can also
6:38 use your NAS with snapshots. Think
6:41 Synology or TRNA. Also run backup jobs
6:45 that grab your documentation folders
6:47 regularly. Now, there's also the good
6:50 old-fashioned print out a physical copy.
6:53 And I do this. I actually like to have a
6:56 picture from the UniFi controller of all
6:59 of my ports on my UniFi network switch.
7:02 What is up linked to those ports, the
7:04 VLANs that are associated, and I can't
7:05 tell you how many times that has saved
7:08 lots of banging the head against the
7:10 wall in a break glass moment when you
7:12 have something in the network go down.
7:14 you're having to unplug things and
7:16 you're trying to remember exactly how
7:18 everything is cabled up. Now, also, I'll
7:20 admit I'm not the best at this, but
7:23 labeling your gear saves you later. Now,
7:26 what are some things that you probably
7:28 want to think about labeling? Things
7:30 like Ethernet cables, power cords,
7:33 server names, VLAN tags, storage bays. I
7:36 can't tell you how many times, and you
7:38 probably can relate to this, when you've
7:40 got a spaghetti ball of cables in your
7:43 network rack or your server rack and you
7:46 think a cable goes to a specific server
7:49 or a specific uplink and you pull that
7:52 uplink and you're wrong. It doesn't go
7:55 to that server or that uplink and you
7:57 take your entire network down. So having
8:00 those labels on physical cabling so you
8:03 can reference that and having the labels
8:05 on both ends just so you know that this
8:08 cable is indeed the cable that I think I
8:11 have when I'm trying to unplug a
8:13 specific server. Now I also use the do
8:16 lettag label printer and I've got a link
8:19 to that specific label maker in the
8:21 description for this video. This label
8:23 maker, it's simple, it's cheap. There
8:25 are many others out there that are
8:26 great, more fancy, that do more things,
8:28 but at the end of the day, all these
8:30 label makers do the same thing. They
8:32 help you not to guess which switch port
8:35 connects with which device 6 months
8:37 later if you have those properly
8:39 labeled. Also, a very important thing
8:41 that I feel like most need to do, and
8:44 myself included, much better in their
8:46 home labs is to track changes over time
8:49 in a simple change log. A simple change
8:52 log.md file works great. Now, what is
8:55 included in this change log file? Well,
8:57 you want to log things like the date.
8:59 What changed? What change did you make?
9:01 No matter how small or how large, why it
9:04 changed, what was the purpose of that
9:06 change? Making that note will help you
9:08 to remember what you were thinking 6
9:10 months ago. Now, also who changed it. If
9:12 you have more than one in a lab
9:14 environment, but especially for
9:15 production environments, that is a
9:17 tremendously valuable thing to have. and
9:20 then also document any problems that
9:22 have occurred due to this change. And
9:24 you'll be amazed at how often this type
9:27 of detailed documentation saves you. And
9:30 if you do it on the front end, and this
9:32 is always what I run into uh that bites
9:34 me in the long run is the fact that I
9:37 think I don't have time to do that. I or
9:40 I will remember to do that much later
9:42 and it never happens. Do the
9:44 documentation on the front end. keep
9:45 that change log among all the other
9:47 documentation so far that we've talked
9:49 about. Also, self-hosting is awesome,
9:51 but what if your network goes down? Now,
9:53 this is something that you really need
9:55 to think about. make sure that you can
9:58 access your docs even if the lab is
10:00 offline. Because the catch22 that we get
10:03 into with our self-hosting habits is
10:06 that yeah, we've got great
10:08 documentation, but it's all stored in a
10:11 Docker container or a VM that is
10:14 currently down. So, how do you get to
10:16 that documentation? Again, I love having
10:18 the basics in a physical document inside
10:21 of my server rack, such as VLANs,
10:23 uplinks, those types of things. The
10:25 physical aspects of your lab are really
10:28 great to have. Then also there are many
10:30 other options that can be included that
10:32 can help you with this. You can
10:33 self-host your wiki but sync your
10:35 markdown with sync thing to another
10:38 location. Use something like MK docs and
10:41 engine X for a static site. keep a
10:43 backup in the cloud or again as we've
10:46 mentioned earlier an external drive and
10:47 then also maybe having one, two, or
10:50 maybe even three hard copies of your
10:52 documentation stored in different
10:54 locations. All right, that's a full tour
10:56 of how to document your home lab the
10:58 right way. It takes effort, but it pays
11:00 off huge dividends when you're
11:02 troubleshooting or you're replicating
11:04 your setups. Now, what tools are you
11:06 using for your own home lab
11:08 documentation? I love to learn from you
11:10 guys and often the comments that you
11:12 make on the videos, you often mention
11:15 containerized solutions or other
11:16 solutions that are open source that I've
11:18 never heard of before and when I get my
11:20 hands on them, they are just fantastic.
11:23 So, please do let me know what you guys
11:25 are using and hopefully some of the
11:27 solutions that I have mentioned so far
11:29 with some of these pieces and parts of
11:32 documentation that are extremely helpful
11:34 in the home lab will be maybe new
11:36 solutions that you've not heard of as
11:38 well. Well, I'm Brandon Lee. Please do
11:40 like, subscribe, and let me know also in
11:42 the comments what you're using. Once
11:44 again, well, please do stay safe out
11:46 there. Keep on home labbing, and I will
11:49 see you in the next video.
Chrome Extension