Re: Examples of existing infrastructures?

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