Con su cuenta de Red Hat puede acceder a su perfil de miembro y sus preferencias, además de a los siguientes servicios teniendo en cuenta su estado de cliente:
¿Aún no se ha registrado? Le ofrecemos varios motivos por los que debería hacerlo:
- Consulte artículos de la base de conocimiento, gestione casos de soporte y suscripciones, descargue actualizaciones y mucho más desde una misma ubicación.
- Consulte los usuarios de la organización, y edite la información, preferencias y permisos de sus cuentas.
- Gestione sus certificaciones de Red Hat, consulte el historial de exámenes y descargue logotipos y documentos relacionados con las certificaciones.
Con su cuenta de Red Hat puede acceder a su perfil de miembro, sus preferencias y otros servicios dependiendo de su estado de cliente.
Por seguridad, si está en un equipo de acceso público y ya ha terminado de utilizar los servicios de Red Hat, cierre sesión.Cerrar sesión
Let's imagine you've had many meetings, internal deliberations, workshops, and decided to put your “Continuous Integration/Continuous Development” environment on Red Hat OpenShift Container Platform (OCP). You’ve defined a problem, a strategy, and a solution. It's now time to decide where in your datacenter to deploy it.
Let's be clear, I'm not ignoring OpenShift Online, nor am I discounting it. I’m simply comparing “on premise” infrastructure solutions for OCP.
When looking at on premise solutions for OCP, there are three options: bare metal, OpenStack, and virtualization. All of the options have clear benefits and detractors; it’s a matter of being aware of the detractors and weighing those against the benefits.
Deploying containers on bare metal provides great performance due to lack of latency for disks or network. It’s also the least complex setup and automating the configuration is as simple as deploying Ansible or Puppet.
On the other hand, just as traditional applications have difficulty in recovering from hardware failure, containers on bare metal can suffer from the same challenges. Additionally, upgrades to hardware require downtime as do reboots to the operating system. While these can be mitigated, they may still require change management.
OpenStack was designed to run distributed workloads, discrete components, and can easily handle containers. One of the primary design factors for OpenStack was scale; that is not in question. It was also built with automation in mind, so that is also a strength.
On the potential downside, OpenStack frequently requires a staff with deep and wide engineering skills to deploy and maintain it. If this staff is already in place and there is already a requirement to support “cloud ready” applications in addition to OCP, then OpenStack is likely a great choice for OCP. Otherwise, OpenStack may be a heavy lift for some datacenter operations staff.
Virtualization fits right between bare metal and OpenStack in regards to performance, automation, and low level of complexity. Where bare metal may require special handling for maintenance and VMs can be live migrated. Virtualization also handles hardware failure more gracefully for applications and containers faster than bare metal. Additionally, where bare metal servers lack consistency across vendors for automated deployments, VMs can be deployed at the click of a button or via APIs.
When compared to OpenStack, virtualization has fewer resource requirements both in people and hardware. Once the deployment is planned out, the virtualization platform can be deployed in a relatively short amount of time, with low level of effort to operate.
Deploying on Red Hat Virtualization
Allow me to take this a step further and make the case for Red Hat Virtualization (RHV) specifically. Deploying OCP on RHV provides many advantages, such as a few listed here::
Common tooling & operations
Both OCP and RHV utilize or can utilize many of the same management or automation tools. OCP comes with CloudForms for operational management and RHV has deep integrations with CloudForms. RHV also has deep integrations with Ansible, which can also be used to automate OCP. Common tooling and management streamlines operations, development, support, and training.
RHV also adds security to containers in the form of SELinux and sVirt. In the context of RHV, each virtual machine is a “process” that gets a security label from SELinux. This kernel-enforced label restricts a VM’s ability to access outside resources including the hypervisor, other VMs, and therefore other containers. Additionally, sVirt dynamically labels VM processes, enabling policy-driven security for the container infrastructure environment.
RHV is sold as a 2 socket subscription; there is no license. This means that it’s all OpEx, no CapEx, and results in a predictable cost model. This model also means that you can purchase additional subscriptions as you grow without having to restructure a contract.
If you’re developing RHEL based containers, on a Red Hat based CI/CD platform, it makes sense to then also deploy that on a Red Hat infrastructure as well. Get direct access to the experts that know how the technologies work together. The single support stack model simplifies operations.
This isn’t just something that we recommend, this is also how we do it at Red Hat, as Eric Brown describes in “Red Hat IT runs OpenShift Container Platform on Red Hat Virtualization and Ansible”. If this is something that you want for your environment, then I also recommend this new reference architecture that provides a walk through of how to deploy OpenShift Container Platform on Red Hat Virtualization.
Hope this helps,