Hosting WordPress barato: comparativa 2020

Hoy os traigo una comparativa de los principales hosting WordPress a Junio de 2020. Para la comparativa, he elegido los proveedores que me han resultado más interesantes siempre centrándome en un pack WordPress económico pero con características suficientes para un proyecto WordPress inicial, independientemente de que estos proveedores puedan ofrecer otros packs WordPress o enfocados a alojar otro tipo de proyectos. Sin más, ¡al lío!

BlueHostionosHostingerSiteGround
Número de webs11ilimitado1
Disco50GB SSD25GB SSD20GB10GB
Base de datosilimitado1GBilimitadoilimitado
DominioGratis 1 añoGratisGratis 1 añoGratis 1 año
SSLGratisGratisGratisGratis
SSH
Instalación 1 click
PanelcPanela medidaa medidacPanel
DatacentersUSA, Europa y AsiaUSA y EuropaUSA, Europa y AsiaUSA, Europa y Asia
Soporte chat
Soporte teléfono
Soporte email
Nombre packWordPress HostingEssentialPremiumStartUp
Precio sin impuestos2.65€/mes2€/mes primer año. 4€/mes resto45€ pago anual3.95€/mes

Como véis, he querido comparar 4 hostings cogiendo planes de similares características, centrándome en los aspectos que considero imprescindibles en un hosting, como son:

  • Espacio en disco y en base de datos
  • La inclusión (o no) del dominio y el certificado SSL
  • Acceso SSH, tipo de panel de gestión e instalación de WordPress en 1 click
  • Tipos de soporte técnico
  • Nombre y precio del pack

La opción que más destaca es la de BlueHost, tanto en precio (es la opción más económica) como en prestaciones; esos 50GB SSD y el espacio ilimitado en base de datos suponen una diferencia con el resto. Sin embargo, tiene un contra importante, y es que la página únicamente está en inglés, lo cual puede ser un problema si no te defiendes en el idioma de Shakespeare.

Bajo mi punto de vista, la segunda opción a considerar sería la de Hostinger. En lo personal, he tenido alojado el blog tanto en Hostinger como en ionos (la antigua 1and1) y mi experiencia con Hostinger fue bastante positiva, mientras que con 1and1 siempre tenía problemas con el pago anual de mi plan de alojamiento y tenía que acabar intercambiando mails con ellos para solucionarme los problemas de facturación. Particularmente creo que Hostinger puede ser una mejor opción que ionos, además de por mi experiencia personal, porque ese 1GB de base de datos, aunque a priori suficiente, puede acabar resultando un limitador de crecimiento de nuestra web.

Todos los hostings comparados, como no podía ser de otra manera, tienen además muchas otras características que quizá te podrían interesar, como el número de subdominios, gestión de cuentas de correo electrónico o incluso algunas como Hostinger anuncian su SLA (del 99.9% de disponibilidad). Si buscas un hosting WordPress que te ofrezca alguna de estas particularidades, no dejes de repasar el listado completo de prestaciones antes de contratar.

Kubernetes – Apuntes del CKA

Bueno, aquí dejo algunos apuntes (ojo, ésto no es una guía ni una biblia; son sólo eso, apuntes) tras repasarme los cursos «Kubernetes Quick Start» y «Cloud Native Certified Kubernetes Administrator (CKA)» de LinuxAcademy.com

Cómo instalar Docker + Kubernetes from scratch en CentOS

Usando Flannel para la gestión de la red.

Dejo un copy&paste de las instrucciones originales de LinuxAcademy.

    #The first thing that we are going to do is use SSH to log in to all machines. Once we have logged in, we need to elevate privileges using sudo.
     sudo su  

    #Disable SELinux.
     setenforce 0
     sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux

    #Enable the br_netfilter module for cluster communication.
     modprobe br_netfilter
     echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables

    #Disable swap to prevent memory allocation issues.
     swapoff -a
     vim /etc/fstab.orig  ->  Comment out the swap line

    #Install the Docker prerequisites.
     yum install -y yum-utils device-mapper-persistent-data lvm2

    #Add the Docker repo and install Docker.
     yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
     yum install -y docker-ce

    #Configure the Docker Cgroup Driver to systemd, enable and start Docker
     sed -i '/^ExecStart/ s/$/ --exec-opt native.cgroupdriver=systemd/' /usr/lib/systemd/system/docker.service 
     systemctl daemon-reload
     systemctl enable docker --now

    #Add the Kubernetes repo.
     cat < /etc/yum.repos.d/kubernetes.repo
     [kubernetes]
     name=Kubernetes
     baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
     enabled=1
     gpgcheck=0
     repo_gpgcheck=0
     gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
             https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
     EOF

    #Install Kubernetes.
     yum install -y kubelet kubeadm kubectl

    #Enable Kubernetes. The kubelet service will not start until you run kubeadm init.
     systemctl enable kubelet

*Note: Complete the following section on the MASTER ONLY!

    #Initialize the cluster using the IP range for Flannel
     kubeadm init --pod-network-cidr=10.244.0.0/16

    #Copy the kubeadmin join command. Exit sudo and run the following:
     mkdir -p $HOME/.kube
     sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
     sudo chown $(id -u):$(id -g) $HOME/.kube/config

    #Deploy Flannel.
     kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

    #Check the cluster state.
     kubectl get pods --all-namespaces

*Note: Complete the following steps on the NODES ONLY!

    #Run the join command that you copied earlier (this command needs to be run as sudo), then check your nodes from the master.
     kubectl get nodes

Nota:
Al final k8s es una capa encima de docker que usa la API de docker para manipularlo. Puedes correr un docker ps en las instancias para ver exactamente qué está pasando por debajo de k8s (en docker)

Continuar leyendo «Kubernetes – Apuntes del CKA»

Yaml essentials

YAML

Inicialmente llamado «Yet Another Markup Language» (YAML), que sin embargo no es un Markup Language, si no que ha acabado siendo un lenguage de serialización de datos fácilmente legible por humanos, razón por la que cambió su nombre a «YAML Ain’t Markup Language».

Pensado para ser fácilmente legible por humanos, por lo que sus casos de uso son:
– Ficheros de configuración
– Almacenage de datos

Sintáxis
– Usa (2) espacios para indentar (nunca tabs!)
– La indentación agrupa cosas que van juntas
– Guiones para listas
– Dos puntos para key: values (atención al espacio tras los dos puntos)
– Usa comentarios con # seguido de un espacio en blanco (o tab)

Estilos:
– Block: el habitual
– Flow: es una extensión de JSON

Tipos
– Mappings: key:values
– Secuencias: array o lista de items, uno por línea precedido de un guión
– Escalares: strings, números o booleanos

Podemos partir un string en múltiples líneas (preservando el salto de línea) mediante «|» o sin preservarlo (pese a tener salto de línea dentro del yaml para facilitar la lectura) con «>»

schedule: |
  2018-10-01 - Whatever here
  2018-10-02 - And here
done_by: >
  A large sentence that
  has been broken into pieces
  but will be presented together.

Estructuras:
– Opcionalmente, un yaml file puede empezar con tres guiones. Ésto es obligatorio cuando usas herramientas como «Ansible».
– Los tres guiones también se pueden usar para separar diferentes documentos dentro de un mismo fichero.

Los anchors sirven para reutilizar datos dentro del fichero yaml. Seteamos la línea o el bloque con &anchorname y hacemos referencia a él con *anchorname.

 
locations:
  &EUlocations
  - Spain
  - Portugal
  - Italy
samelocations:
  *EUlocations

Más info
https://yaml.org/start.html
Linux Academy: Yaml essentials

Site Reliability Engineering (SRE): principios

He querido resumir en un post, los principios que se explican en el libro «Site Reliability Engineer» de Google (gratis y online).

CAPITULO 1 & 2 – INTRO

Además de programar, a un SRE se le pide conocimientos avanzados de cómo funciona el sistema UNIX a nivel interno, y de networking (capas de la 1 a la 3)

La clave está en dedicar al menos un 50% del tiempo en automatizar las tareas de operaciones o a hacer tareas de ingeniería (mejorar la fiabilidad, el performance, etc.). De esta manera, evitas tener un equipo que crezca a la vez que crece la infraestructura (y por tanto, las tareas de operaciones si no estuvieran automatizadas).

También es clave dedicarle tiempo a los postmortem para aquellos incidentes relevantes. En caso contrario, no se estará aprovechando la oportunidad de mejorar nuestros sistemas.

El concepto de «error budget» es (1 – disponibilidad_acordada). Si se establece 99.99% de disponibilidad acordada, el error budget será de 0.01%. Este error budget se podrá usar para lo que se quiera, pero típicamente se usará para tomar riesgos deployando nuevas funcionalidades lo antes posible.

Aprox un 70% de las caídas son debidas a cambios en producción. Los SREs deben aplicar best practices para automatizar completamente los cambios (progresivos) en producción así como el rollback.

Las alertas del sistema de monitorización deberían interpretarse y solucionarse de forma automática, y a partir de ahí, únicamente deberían notificar a un humano cuando éstos necesiten tomar parte.

Continuar leyendo «Site Reliability Engineering (SRE): principios»

Site Reliability Engineer

Bueno, ha llegado el día en el que publico un resumen (muy básico y que seguramente iré actualizando) de lo que entiendo es un SRE y sus funciones básicas. Allá vamos.

¿Qué es un SRE?

Hay muchas definiciones de lo que es un SRE, pero me quedo con ésta de Microsoft:

Site Reliability Engineering is an engineering discipline devoted to helping an organization achieve the appropriate level of reliability in their systems, services, and products.

Y que complemento con esta frase sacada del libro de SRE de Google:

In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s).

Hago especial hincapié en lo de conseguir los niveles de fiabilidad apropiados. El 100% de uptime no es el objetivo de un SRE. En realidad, una caída del servicio no se ve ya como algo «malo» si no que es una oportunidad para que los desarrolladores y los SREs mejoren los sistemas.

Continuar leyendo «Site Reliability Engineer»

Cómo lidiar con unassigned shards en Elasticsearch


Lo primero es lo primero, saber qué significa el estado del cluster de elasticsearch:

  • Green: Cluster 100% operacional con todos los shards, tanto primarios como réplicas asignados.
  • Yellow: Todos los shards primarios asignados, pero al menos hay problemas con una réplica. El funcionamiento de las búsquedas no se ve afectado, pero la alta disponibilidad del cluster podría estar comprometida.
  • Red: Al menos un shard primario tiene problemas. Tus búsquedas devolverán resultados incompletos y el indexado podría devolver alguna excepción.

Fuentes: [elastic.co] [chrissimpson.co.uk]

Red cluster. ¿Y ahora qué?

En el siguiente ejemplo, vemos un cluster en estado RED, con 2 shards no asignados.

[ec2-user@myfakeserver ~]$ curl http://elasticsearch.myfakecluster.com:9200/_cluster/health?pretty
{
  "cluster_name" : "myfakecluster",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 6,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 44,
  "active_shards" : 88,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 2,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 97.77777777777777
}

Muchas de las ocasiones en los que me he encontrado con un cluster con unassigned shards ha sido por falta de espacio en disco, ya sea porque el cluster en sí se estaba quedando sin espacio, o porque había caído alguno de los data nodes. Así pues, tras verificar que no haya problemas de espacio, seguramente deberíamos revisar que el cluster tenga el número y tipo de nodos esperados.

[ec2-user@myfakeserver ~]$ curl -s http://elasticsearch.myfakecluster.com:9200/_cat/nodes?v
ip            heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
10.10.13.74            62          69   1    0.01    0.01     0.00 m         *      i-00e943d383ac0e36a
10.10.12.224           10          74   0    0.00    0.00     0.00 di        -      i-0fb30da02fa44654f
10.10.14.191           17          68   1    0.30    0.16     0.05 m         -      i-0c3f5e9ffe51580de
10.10.13.26            10          75   0    0.00    0.00     0.00 di        -      i-088d4398987bbcbe4
10.10.14.79            21          71   0    0.00    0.00     0.00 di        -      i-0d02b207abeb67c6b
10.10.12.4             34          68   1    0.04    0.03     0.00 m         -      i-087e0c009c10493d6

Continuar leyendo «Cómo lidiar con unassigned shards en Elasticsearch»

Firma tus commits de git con GPG


El objetivo de esta entrada no es más que resumir los pasos que haríamos para empezar a usar git en nuestro PC. Linux, por supuesto. Básicamente en esta entrada veremos cómo setear los parámetros mínimos de configuración global, y cómo dejarlo listo para poder firmar nuestros commits (en GitHub), para que el resto de compañeros puedan confiar en que nuestros commits han estado hechos, en efecto, por nosotros.

Setear nuestro usuario en la conf global de git

Lo primero para empezar a usar git en nuestro sistema es setear nuestro usuario y email. Lo haremos en la configuración global de git y básicamente seguiremos los pasos aquí descritos.

[adri@helloit ~]$ git config --global user.name "Adrian Perez"
[adri@helloit ~]$ git config --global user.email "[email protected]"
[adri@helloit ~]$ git config --list
user.name=Adrian Perez
[email protected]

Vale, ¿pero qué es la configuración global? En git, básicamente, contamos con tres niveles de configuración:

  • /etc/gitconfig: Contiene los valores que se aplican a todos los usuarios del sistema y a sus repositorios. Este es el fichero que se modifica/consulta al pasarle la opción «–system» al hacer «git config». Requiere permisos de superusuario.
  • ~/.gitconfig or ~/.config/git/config: Define los valores configurados para tí, el usuario. Aquí usaríamos la opción «–global» en el «git config».
  • .git/config: finalmente, tenemos el fichero config dentro del propio repo de git. Define los valores específicos para ese repositorio.

Continuar leyendo «Firma tus commits de git con GPG»

EBS/RDS Snapshots

¿Cómo funcionan los EBS snapshots?

Los snapshots de EBS son incrementales (excepto el primero que hagas sobre un volumen EBS); únicamente incluyen los bloques modificados desde el último snapshot. Cada snapshot contiene la información necesaria para hacer un restore completo de tus datos hasta el momento de hacer el snapshot, es decir, contiene referencias a los snapshot anteriores, lo que permite realizar un full restore (hasta el momento de hacer el snapshot) a partir de ese determinado snapshot.

[Fuente]

¿Se puede eliminar un snapshot EBS de forma segura?

Cuando eliminas un snapshot, solamente se eliminan los datos únicos de ese snapshot. Es importante recalcar que aunque el snapshot se elimine, los datos referenciados por otros snapshots se mantendrán. A la práctica ésto significa que si no necesitas poder hacer restores desde las fechas/horas específicas en las que se realizaron los diferentes snapshots, puedes eliminarlos todos excepto el último, que aun así podrás realizar un restore completo.

[Fuente]

Continuar leyendo «EBS/RDS Snapshots»

Un primer vistazo a Puppet


Bueno, hoy traigo un popurrí de conceptos sobre Puppet que espero sirvan para tener una primera idea de algunas de sus características y opciones. Si eres un master of puppets, éste no es tu post.

Puppet es una de las herramientas de gestión centralizada de servidores (y workstations) más conocidas. En su página web, ofrecen varios videos gratuitos que explican con más detalle qué es y cómo funciona.

Bolt y Puppet Tasks

Bolt: standalone, opensource agentless task runner para ejecutar ad-hoc imperative tasks en entornos pequeños.

$gem install bolt

Puppet tasks: para resolver tareas que no encajan bien en el modelo tradicional puppet. Las Puppet Tasks son una forma simple y rápida de actualizar paquetes al instante, reiniciar servicios o ejecutar cualquier otro tipo de acción similar en tus nodos.

# Ejecuto un comando en dos nodos (boron2 y boron5)
$bolt command run "netstat -an | grep 'tcp.*LISTEN'" -n boron2,boron5

# Pongo mis comandos en un script en cualquier lenguaje que entiendan mis nodos. 
# Este script se copiará a los nodos, en un dir temp, lo ejecutará, devolverá 
# el output y después lo eliminará
$bolt script run myscript.sh -n boron-2,boron-5

Continuar leyendo «Un primer vistazo a Puppet»

Apuntes de Python 3 (3ª parte)


Tras año y medio desde la segunda entrega de los Apuntes de Python, llega la tercera entrega, con únicamente un par de secciones bastante genéricas (comunes a muchos lenguajes de programación) y unos cuantos snippets a modo de resumen. Pero antes de nada, te recuerdo los enlaces que preceden a este post:

Guía de estilo para Python

  • Usa (4) espacios en lugar de tabular
  • Nombra a tus variables y a tus funciones en minúsculas usando «_» como separador. i.e. return_code
  • Nombra a tus constantes en mayúsculas y de nuevo, usando «_» como separador. i.e. MAX_SIZE
  • Puedes usar comillas simples o dobles para strings [Más info]
  • Para strings con triple comilla, usa siempre comillas dobles. i.e. «»» Aquí el docstring «»»
  • Usa 2 líneas en blanco antes de funciones y definiciones de clases
  • Usa 1 línea en blanco antes de métodos dentro de una clase
  • Dentro de las funciones, usa una línea en blanco para separar secciones lógicas
  • Respecto a los comentarios, deben ser frases completas. Dejando un espacio entre la almohadilla y el comentario, empezándo en mayúscula y acabando la frase con un punto.

[Más info] [Y más]

Continuar leyendo «Apuntes de Python 3 (3ª parte)»