3 Best Practices When Using Qovery
Qovery provides fast implementation and maintenance of your cloud infrastructure while taking care of end-to-end DevOps tasks. It even manages your Kubernetes clusters for you. It gives developers autonomy because it is effortless and does not need a vast DevOps workforce. With a few clicks, a developer can create a replica of the production environment and deploy their code easily, but where should you start, and with what? This series of articles: Best Practice, will walk you through the first things you should set up in Qovery and how to do it.
Albane TonnellierNovember 7, 2022 · 4 min read
Role-based access control (RBAC) restricts access based on a person's role within an organization and has become one of the primary methods for advanced access control. The roles in RBAC refer to the levels of access that employees have to the network.
Employees can only access the information necessary to perform their job duties effectively. Access can be based on several factors, such as authority, responsibility, and job competency. In addition, access can be limited to specific tasks, such as the ability to view, create, or modify.
- Maximizing efficiency: Your employees will only be able to use what they need in Qovery to do their job.
- Avoid big mistakes: We will talk about it more in-depth in the following example, but your production is precious; you don’t want everyone to be able to touch it and maybe accidentally delete it.
- Improving compliance: All organizations are subject to federal, state and local regulations. With an RBAC system in place, companies can more easily meet statutory and regulatory requirements for privacy and confidentiality.
Straightforward, head to the V3 Console, then to the organization settings, and you will find a Roles & Permissions Panel.
From there, you can add roles to every member of your organization or even create your own. To know which level of permission each role gives you, head to our documentation.
In multi-cluster Kubernetes, you have more than one cluster for your application. These clusters can be replicas of each other, and you can deploy multiple copies of your application across these clusters. Each cluster is placed on a separate host and in a separate data center to achieve high availability. That ensures that any infrastructure loss or cluster breakdown does not impact other clusters in the solution. Although we can have multiple clusters on the same host and in the same data center to save some cost, it will deprive us of the true benefits of high availability.
While the Production Cluster is for end-user applications to which the client has access, the Staging Cluster is used for iterations/testing and validation before releasing in production - to the client. The main idea behind a staging cluster is to mimic the production cluster.
There are three main reasons why you should use a separate cluster for production and staging:
- Performance: Isolation of the production environment, so you can take care of testing a new version of Kubernetes in staging without impacting the production.
- Security: Lock access to the prod cluster. You can decide to give access to the production cluster to a reduced number of people, so it reduces the risk of human error.
- Productivity: Iterate faster and release with confidence, to never be scared of doing changes on your staging cluster before releasing it in production. You will never break your production application while testing and prevent failure in production before they happen.
Once you created your organization, head to the “organization settings” and select “add a cluster”. You will then need to deploy one cluster for your staging and repeat the operation for your production cluster! To have the tutorial in detail, you can head to this article.
Databases can operate in two modes:
Managed databases are perfect for production - they are provided and managed by major cloud providers like AWS to ensure your production data is well managed.
Container databases are managed by Qovery as Docker containers with attached persistent storage. They are perfect for development and testing, as they are significantly cheaper than services provided by cloud providers.
Let's assume you have a production and staging environment and a test and dev environment.
Managed mode for Production and Staging
- To ensure your production data is well managed.
- To ensure that you have backups.
Container mode for Test and Dev Environment
- Qovery manages them as Docker containers with attached persistent storage, so they are much cheaper than services provided by cloud providers
- Still reliable but without backups. That’s why you can’t use them in staging and production.
- Navigate to Console
- Select your project and environment
- Click Add Database button
- Select database type, name, version, mode and accessibility
- Deploy the database using the Action deploy button
Whether it’s for safety reasons, productivity, or to optimize your costs, we hope that those best practices will help you make the most out of Qovery, and while we will be back for another part of this series soon, don’t hesitate to share which best practices you implemented first.