![]() My generic answer here is to grab Elasticsearch, Kibana, and Logstash. We must also give proper consideration to monitoring and logging hoovering at this point. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. I should probably digress here for a moment and explain why. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. ![]() It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. ![]() I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is )). Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ). Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.Scalability: All-in-one framework for distributed systems. ![]() Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts: Redis as preferred in-memory database/store (great for caching).PostgreSQL as preferred database system.Amazon S3) for deploying in stage (production-like) and production environments SSLMate (using OpenSSL) for certificate management.nginx as web server (preferably used as facade server in production environment).Heroku for deploying in test environments.Kubernetes as cluster management for docker containers.VirtualBox for operating system simulation tests.Docker Compose for multi-container application management) Prettier / TSLint / ESLint as code linter.CircleCI for continuous integration (automatize development process).Respectively Git as revision control system.GitHub Pages/ Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool Our whole DevOps stack consists of the following tools:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |