1:04 a.m.
On 29 Mar 2021, at 00:25 , listerin <listen(a)cryptoban.de>
wrote:
hi everyone,
often, when researching / debugging debops specifics, I am confronted with my inability
to immediately grasp a certain role's importance in the larger picture. E.g. right now
I am redesigning my inital debops lab to correctly implement LDAP. Before I did this, I
redesigned it so I could have all new machines directly provisioned by pxe/tftpd/preseed.
I mean, for me that's half the fun, debops has already taught me so much of how a
datacenter works internally, things, I couldn't even imagine only half a year ago.
Still, it's a hard learning curve.
As said, I'm rather new in all of this sysadmin stuff. Seeing example code of how
other people use debops in more fleshed out environment would really interest me. I hope
to gain answers to questions like
- How and especially in which order do you bootstrap/provision a completely new
environment? (e.g. on a hypervisor or a cloud provider)
It depends :)
I’m running a couple of ProxMox clusters on bare-metal servers. Those I do the ZFSonRoot
installs from CD, and manually configure into the cluster (small enough to not have a gain
in the installation automation costs) and use a “jump host” playset on another “separate
and separately protected” environment that I use for creating users etc. on the OS levels
and automate those tasks like SCC (System Configuration Collector), NetData, etc.
deployments to the hypervisors.
I then have jumphosts that I created from my initial debian template (in Qemu/KVM VM
cases, else the normal LXC container with the login details filled in at creation time)
that is also provisioned from the same “jump host” as I use for the ProxMox hypervisors.
There I configure the setup for Ansible/Debops as well as the various client’s logins to
their jumphost.
I then have “Stacks” that is deployed via each stack’s jumphost configured above.
My bootstrap “tip” for VMs: do a minimal Debian (netinstall) with a user named debian pass
debian. You then clone it and assign a MAC address to it, and that MAC is registered in
the DHCP server to assign a fixed IP, then the bootstrap is a way of including a 2nd
inventory file with that user and password in to do the ssh known_hosts, the ansible
minimum/raw installation, the actual users, and then then next script/step is with only
the real inventory file playing what you want and need (Like me vigorously killing and
removing anything FERM/tcpwrappers related as I’m already behind firewalls etc.)
- How are the roles separated onto different hosts? provisioning
order, network design, security zones, etc.
Depends yet again on the specifics for each stack, but my main template had been:
FortiGate-VM Firewall on the hypervisor’s public interface, connecting to the jumphost in
a DMZ and the production/staging/dev/qa servers each in their own subnet, only reachable
via the jumphost for port 22 and only the front-end webserver accessible from the
outside.
As I have a proper FortiGate-VM in play, I can do proper limiting of outgoing traffic and
SSL deep inspection of outgoing traffic so that way I also force as much as possible
DNS/apt-caching/etc. to internal servers, nd the devs needs to help me specify the
specific outside resources they need to access.
- How to work with jump hosts and ansible controllers?
See my methods above.
- Do you include other tools? (e.g. terraform)
I don’t I ignore AWS as they are too expensive and not a value add for me and my clients.
- How do you handle secrets?
yeah… THAT is a problem… also said: steered clear from any public “open” repos so it’s a
problem but not that big. The biggest secrets at present in my GIT repos of my clients,
are the DB connections (only accessible from the application server… and there it’s
typically ALSO in the “open” for the application that is accessible from the outside’s
user ;()
And my initial question, which I have spent the evening pondering on:
how do I solve the problems of order? right now I want an ldap-joined ansible controller,
whose debian is preseeded by a PXE-Server, of course provisioned by that same ansible
controller :-)
yeah well, beware of over automation ;)
There is this joike out there about the DevOps programmer that needed to restart a service
once a month. He/she went on a 2 week long design and testing in the DEV environmnet and
another week’s repeatibility testing in the QA environment before spending another 2days
deploying it to the Production environment so that every motnh, he/she could open a web
browser, browse to a website, login with a username, password and 2FA, to press a button
that would pop up another dialog box to confirm restart…. which then would do a “ssh
remote server -t /etc/init.d/service restart”…
Pick which is the best for your time and efforts ;)
tl;dr: I'd be really glad if somebody wants to share some of
their projects or point me to ressources that discuss more "meta" questions of
provisioning like the ones above.
thanks for debops, it's become my new favorite hobby