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.) 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. See my methods above. I don’t I ignore AWS as they are too expensive and not a value add for me and my clients. 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 ;() 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 ;)

jump-hosts are also my ansible”controllers” :) WAN | FW - jumphost / ansiblec-contrller | LANx FW has multiple (v)LAN interfaces. Jumphost separate (v)LAN

On mar 29, listerin wrote: Hello, listerin. :-) Keep in mind that DebOps and Ansible are just a set of tools that provide abstraction to the underlying Linux ecosystem. Since you wrote that you are starting with system administration, I'm curious - did you try managing a host or two by hand, without any automation? I don't mean setting up Linux From Scratch here, of course, but say, installation of a basic Debian Stable on a host without any desktop environment, just SSH. After that you can try setting up various services on it. Knowing how Linux, and subsequently Debian Linux (different distributions do things differently) can be really helpful in understanding why certain DebOps roles exist and how they are intertwined together. If you want to have some help during the initial steps, Debian Handbook[1] is an excellent resource that explains the installation process and configuration of various services. Another good resource that could help you learn about data centers in general is the Infrastructures.org[2] website, especially its Checklist[3] section. It describes how to set up an old-school data center, especially defines a correct order of services to focus on. It was written about 20 years ago so specific tools are probably outdated by now, but general concepts about order of things and the services you should provide in a data center are still relevant. The last resource I would like to point out is the Ops School[4]. It's a modern take on a data center design, written by the community. Some of the sections are still empty, but hopefully it will be expanded over time, perhaps even with help of the DebOps community. [1]: https://debian-handbook.info/ [2]: http://infrastructures.org/ [3]: http://www.infrastructures.org/bootstrap/checklist.shtml [4]: https://www.opsschool.org/ As for examples specific to DebOps itself, it's probably a bit outdated now, but 'debops/examples'[5] repository on GitHub contains a few working examples. There are plans to integrate this better with DebOps documentation, perhaps integrating these examples with the DebOps Vagrant setup could be useful. A few people published their DebOps-based projects on GitHub, you can check these out for inspiration. DebOps-WordPress[6] was one of the first such projects. Erethon's repository[7] contains more examples and extra roles he wrote that integrate with the project. There's also trustroots[8], freephile[9], russel's[10], Turnkey[11] and tonin's[12] repositories which contain DebOps project directories used to setup various infrastructures. [5]: https://github.com/debops/examples [6]: https://github.com/carlalexander/debops-wordpress [7]: https://github.com/Erethon/ansible-debops-infrastructure [8]: https://github.com/Trustroots/trustroots-debops [9]: https://github.com/freephile/qb3 [10]: https://github.com/russelltsherman/proj-debops [11]: https://github.com/jstruebel/tkl-debops [12]: https://github.com/tonin/MyDebops With a completely new environment, I would try and find all the quirks the provider has - do the hosts have the proper DNS PTR records available, are 'ansible_hostname' and 'ansible_fqdn' variables resolved properly, and so on. When you have the bootstrap.yml playbook working as expected, it's all pretty easy from there. I usually apply the common.yml playbook first and then inspect the host to see if basics are set up correctly - PKI realms, firewall, expected UNIX groups and user accounts. Afterwards, it all depends on the purpose of a given host. It all depends on the available resources. Do you have access to a single beefy hardware machine? Just cram everything in there, most DebOps roles are designed in such a way that there shouldn't be conflicts. If you can set up as many VMs or containers as you want, then it might be a good idea to separate different applications into different hosts, or even create multiple instances of a given application with proper redundancy. Some roles like slapd are designed with this kind of operation in mind, check their documentation. The 'site.yml' DebOps playbook has the order of various roles designed pretty well, from setting up basic host services like firewall, SSH, networking, then further to various databases and backend services, finishing on end-user applications like GitLab and Nextcloud. If you plan to write your own roles to deploy applications, it's a good practice to check the playbooks of similar software stack included in DebOps to see what might be needed for your software deployment. The SSH protocol is pretty versatile here. You can set up a basic bastion host with only DebOps 'common.yml' playbook, and open up SSH connection to the entire world (just use the SSH keys for authentication, make sure that password authentication is disabled). The rest of the infrastructure can have SSH disabled from the outside via firewalling. In ~/.ssh/config file you can define that connections to hosts on a particular domain should go though the bastion host: Host *.example.org !bastion.example.org ProxyCommand ssh bastion.example.org nc %h %p And in the ansible inventory, just define the hosts as normal: [debops_all_hosts] bastion ansible_host=bastion.example.org webserver ansible_host=webserver.example.org As long as your Ansible Controler and bastion host can resolve the DNS records of the hosts you use correctly, SSH should connect via the bastion. After that, it's all transparent. At the moment I don't use Terraform or similar tools to provision the uderlying hosts, I don't have a development environment to try that yet. In the future I would like to add support for OpenNebula to DebOps. OpenNebula provides an AWS-like API which could then be utilized by Terraform to set up VMs. But it will take some time to do this properly. Stay tuned. Secrets are handled by the 'debops.secret' role with either EncFS or git-crypt to provide encryption at rest. Of course it's best if you use that on top of an encrypted filesystem to not leave traces on the hardware, and don't publish repositories with secrets on public websites like GitHub to minimize exposure. It's a chicken-and-egg problem you won't solve in one step. I would start by provisioning the initial host via Debian-Installer, on which you can install the DHCP/DNS/PXE services (for example with dnsmasq). Using it, you can install and configure two LDAP hosts in a cluster that will provide the directory services to the rest of the cluster. You can bootstrap then with the 'bootstrap-ldap.yml' playbook if you wish, just skip the 'ldap' tasks initially: debops bootstrap-ldap -l host -u root --skip-tags skip::ldap:tasks,skip::sudo,skip::apt_mark debops common service/slapd -l host -u root --skip-tags skip::ldap:tasks,skip::sudo,skip::apt_mark This will let you provision the host when LDAP directory is not available yet. Other roles are skipped because at this stage they might cause issues due to lack of LDAP connections. After host is set up with the slapd role, you can create the initial admin account with the 'ldap/init-directory.yml' playbook. When you make sure that you can connect to the directory with a client, for example Apache Directory Studio, you can then re-bootstrap the LDAP hosts with all the services: debops bootstrap-ldap -l host -u root The roles should now create the apropriate LDAP objects in the directory and configure the hosts to use the directory for UNIX accounts and groups. From there, you can deploy new hosts using 'bootstrap-ldap.yml' playbook as usual. Since your initial DHCP/DNS/PXE host was deployed without LDAP support, you should create a new one with LDAP support enabled, and decomission the old one. Or you can set it up initially with LDAP tasks skipped and then re-bootstrap it the same way as the LDAP hosts. Over the years developing DebOps and helping people debug issues in their infrastructure I can say that each person's environment is different. It all depends on the purpose of the infrastructure - web applications will have different requirements than a HPC cluster, which will have different requirements than a backup storage array. The recent trend of going into the Cloud can cover probably 70%-80% of common use cases pretty easily, especially when you just get perpared VMs for your applications akin to Heroku. But handling your own infrastructure properly from the ground up is still a skill which you acquire over years of practice. So don't get discouraged if you stumble on a roadblock - everything can be either fixed or redesigned if necessary. If you have any more questions, let us know. Cheers, Maciej