YouTube Transcript:
Home Lab Documentation // Tools Tips and Tricks!

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