Cómo instalar una aplicación Django en OpenShift

OpenShift es la plataforma PaaS de Red Hat. Aunque este post trata sobre consejos y experiencia de instalar una app de Django, hay que decir que OpenShift está actualmente montado sobre Amazon Web Services y que utiliza el concepto de recurso (gear o cartucho).  Un “cartucho” puede ser una aplicación web, una base de datos MySql, una instancia de memcached, etc. La cuenta gratuita permite tener 3 cartuchos. La idea es que si tu solución necesita escalar, fácilmente se puede añadir nuevos cartuchos bajo demanda.

Aquí os presento algunos tips o problemas con los que me he encontrado:

  • Lo primero es instalar el toolkit de OpenShift, rhc. Se trata de un script Ruby con el que se puede crear aplicaciones, ver logs, acceder via SSH etc. Se instala con “gem install rhc”. A mi me dio un error al instalar parte de la documentación pero funciona sin problemas.
  • La primera vez que se ejecuta rhc nos pedirá los credenciales de OpenShift (login/password) y permite crear y subir una clave pública de SSH para acceder sin tener que recordar clave alguna.
  • Para acceder vía SSH, ejecutamos “rhc ssh <app>“. Esto llama a SSH utilizando la clave pública. Como usuario, se utiliza un string-ID bastante largo. Al acceder nos situa en el “home” virtualizado: /var/lib/openshift/<UserID>. En ese directorio aparecen los componentes principales de tu aplicación. Para una aplicación Django son: app-root, git y python. La mayoria de los directorios son de sólo lectura. Solo en $HOME/app-root/data, $HOME/app-root/repo y algún que otro directorio podemos escribir.
  • Si necesitamos instalar algún componente Python, deberemos de ejecutar el script de Virtualenv. Esto se hace con “source $HOME//python/virtenv/bin/activate”. Luego ya llamaos a “pip install <paquete>“.
  • En caso de tener que copiar algo vía SCP, deberemos tener cuidado de que el directorio destino tenga permiso de escritura. Esta seria una sintaxis válida “scp <fichero> <userID>@<app>-<cuenta>.rhcloud.com:/var/lib/openshift/<userID>/app-root/data“.
  • El entorno de OpenShift establece un número grande de variables de entorno que será de gran utilidad para configurar tu aplicación. Todas comienzan por “OPENSHIFT_”. Por ejemplo OPENSHIFT_APP_DNS nos da el host,  OPENSHIFT_REPO_DIR el directorio donde se ubica el repositorio o OPENSHIFT_PYTHON_LOG_DIR donde se encuentran los logs de Apache.
  • El equivalente a “service httpd restart” es “ctl_app restart“. Lo utilizaremos cada vez que hagamos algún cambio en la aplicación.
  • La mejor forma de enlazar nuestra aplicación con wsgi es fijarnos en el ejemplo que viene. Apache ejecuta $HOME/app-root/repo/wsgi/application para cada request. Este script prepara el entorno de virtualenv e invoca al manejador wsgi de Django. Debemos ajustar los paths y nuestro “project.settings”.
  • Lo más normal es que durante la instalación de nuestra app nos encontremos con errores tipo 500. Con “rhc tail”, veremos los logs de Apache.
  • Los contenidos estáticos deben ir a $HOME/app-root/repo/wsgi/static, luego debemos configurar correctamente la variable STATIC_ROOT para que apunte al path correcto dentro de settings.py.
  • Si nuestra aplicación usa base de datos, se recomienda la ubicacion $HOME/app-root/data, ya que $HOME/app-root/repo se destina al repositorio de código.
  • Es posible tener una configuración especifica según el entorno de ejecución mirando las variables de entorno. En el ejemplo que viene por defecto, se crea una variable booleana ON_OPENSHIFT dentro settings.py que se usa para determinar la ubicación de la base de datos sqlite3.
  • Si queremos obtener la IP de aquellos que nos visitan, tenemos que usar el meta “HTTP_X_FORWARDED_FOR” en lugar “REMOTE_ADDR”.
  • Por último, si queremos asociar un CNAME a nuestra app, usamos “rhc alias <app> <cname>” para crear dicho alias (imagino que añadirá un ServerAlias a la configuración de Apache).

Sin duda OpenShift es de las plataformas más económicas (o gratis) de hospedar un proyecto Django. Muy recomendable para aplicaciones inicialmente pequeñas o prototipos.

 

Anuncios

Red Hat Tour 13 Madrid

Red Hat Tour 2013 Madrid en el Santiago Bernabéu

Red Hat Tour 2013 Madrid en el Santiago Bernabéu

El pasado día 16 de Abril tuvo lugar el Red Hat Tour 13 en Madrid. En esta ocasión no se celebró en el típico hotel de turno, sino que se desarrolló en todo un monumento vivo de la Villa de Madrid, el estadio Santiago Bernabéu.

Este evento que se celebra cada año y medio aproximadamente tiene como título “Transform your IT“. En líneas generales viene a presentarnos lo último que los chicos de Red Hat  y sus patners (HP, Bull, Intel, Fujitsu, etc) están trabajando, sus apuestas de futuro inmediato y los casos de éxito.

El tema diagonal de todas las charlas fue el cloud computing. Siendo un poco más específico, los términos que más aparecieron en las distintas sesiones fueron “cloud abierta, cerrada e híbrida”.

Yo soy de los que piensan que esto del “cloud” no es más que un producto de marketing asociado a dos viejos conocidos: red y virtualización.

Según Wikipedia, una nube privada no es más que una nube destinada a ser explotada por una organización. De todos los casos de nube privada que presentaron, el que más me llamo la atención fue el renderizado de películas 3D de DreamWorks. Antes de la nube, ellos tenían montado un IT propio que era muy caro de mantener y encima no daban a basto cuando querían producir una película (según dijeron tardarían 7.000 años para hacer el  renderizado en un solo PC de alta gama). Lo peor de esto es que cuando no había película que renderizar, el sistema estaba ocioso. Así fue como acudieron a los servicios de consultaría de Red Hat y apostaron por la nube para reducir drásticamente el precio y conseguir sacar las películas según la planificación.

Para Red Hat las ventajas de una nube open source son claras: escalabilidad, velocidad y no lock-in. En entornos cada vez más competitivos con menor presupuesto y mayor exigencia, poder lanzar una solución rápidamente, hacer que escale según la demanda para no desperdiciar ningún recurso y que puedas seleccionar qué proveedor te va dar solución para según qué subsistema sin problemas de dependencia se convierte en un “must“.

De los pocos productos hardware que se vieron, me llamo la atención el HP Moonshot. Se trata de un nuevo concepto de rack que puede albergar hasta 45 unidades de lo que denominan “cartuchos”. Un cartucho puede ser una CPU, un disco SSD, un servidor NAS o incluso una FPGA. Para mi es el mejor “mapeo” de la nube en una nube física.

Respecto a las nuevas tecnologías open en las que Red Hat y sus patners están trabajando, destacaría OpenStack  (“el sistema operativo de la nube”). El objetivo es estandarizar la gestión de nubes públicas, privadas e híbridas. Esto viene muy bien para la interoperatividad entre proveedores de cloud.

Un nuevo servicio que me gustó especialmente fue OpenShift (el nombre no es muy acertado, esperemos que funcione bien). Este servicio es un PaaS de Red Hat que te permite  alojar una aplicación en el cloud abierto de Red Hat. Es insultantemente rápido hacer un deployment de un aplicación alli. Me registré y con dos click tenia andando un WordPress a estrenar. Lo mejor de todo es que hay un plan gratuito, luego se puede tener un WordPress totalmente modificable pero como si estuviera alojado en WordPress.com. Una pasada.
El principal problema que le veo a OpenShit es que hoy en día corre sobre Amazon Web Services (IaaS). Además de esto, todavía no admite SSL para tu dominio (tiene un SSL wildcard para *.rhcloud.com)

Para (casi) terminar, decir que he echado en falta la ausencia de ARM como alternativa a la arquitectura x86 para servidores y que no me cabe duda que le quitara cuota de mercado. Ya existen proyectos amateurs de cluster y supercomputadores que tienen el tamaño de una tarjeta de crédito que usan ARM como CPU. También brillo por su ausencia el término “mobile”, lo cual deja claro donde se posiciona Red Hat, dejando a distribuciones como Ubuntu que experimente en ese difícil terreno.

Por último, felicitar a Red Hat por el gran evento que ha organizado. El contenido de las charlas, el desempeño de los ponentes, el timing, la ubicación, etc estuvo muy a la altura.
¿dónde será el próximo Red Hat Tour 15? ¿Las Ventas? 🙂

El primer Hackathon DEV&BIZ, Betabeers & IE Business School

Betabeers Hackathon Dev&Biz

Betabeers Hackathon Dev&Biz

TL;DR: 1º Hackathon que une desarrolladores de software y de negocio. El tema fue “nuevas formas de vender videojuegos”. No hubo ninguna idea “killer“. Experiencia muy  enriquecedora, mucho networking y sobre todo buen rollo y diversión.

El pasado 15 de Diciembre se celebró en el Área 31 de IE Business School, el primer hackathon que reunia Business y Software Developers.

Con algo de demora, el hackathon empezó sobre las 10 am.

El grupo canónico estaba formado por 3 desarrolladores y 3 business developers que tenian que desarrollar un proof-of-concept sobre el tema: “Nuevas formas de vender videojuegos

Se presentaron muchas ideas y propuestas sobre la mesa, al final se desarrollaron unas 6 propuestas que describo a continuación:

  • UGame
    • La hipótesis de los chicos de UGame es que a todo el mundo le gustaría hacer su propio videojuego. Su propuesta consiste en que alguien crea un nivel y luego se lo manda a un amigo para que juegue y continue su desarrollo.
    • Modelo de negocio: Cuando se recibe un mini-juego, se presenta un breve anuncio antes de dar paso al juego.
  • 6-Games
    • Se presentan 6 juegos en modo “slide-run” donde tienes 30 segundos para jugar. Pasados esos 30 segundos, no te deja jugar más y puedes poner un rating al juego antes de pasar al siguiente. El objetivo es que puedas probar los juegos y decidir cúal comprar.
    • Modelo de negocio: Hay varias formas de explotarlo. Desde el punto de vista de cliente final, puede evaluar que juego le gusta más y comprarlo directamente, llevándose una comisión. Desde la posición de desarrollador, puede ver el feedback/valoración que recibe su juego y así tomar medidas. En principio no pagan por publicar juegos.
  • GamesLover
    • “¿Quieres un juego a buen precio? Pues ayuda en su promoción mediante su difusión en redes sociales”. Esta es la idea. Cuanto más promoción hagas por un juego, mayor descuento obtendrás.
    • Modelo de negocio: Programa de afiliación, los juegos incluidos en este catálogo tiene mayores oportunidades de vender.
  • FinderGames
    • Facilita a los padres la búsqueda del juego correcto para su hijo. Mediante preguntas sencillas, pretende acertar con el juego correcto para los retoños.
    • Modelo de negocio: Afiliación y/o comisión por ventas de juegos.
  • Otogami App
    • Otogami.com es un web española creada por David Bonilla que permite encontrar juegos al mejor precio de mercado. Otogami App es la versión app de la web que  mejora la UX y añade nuevo canal para llegar al cliente con la facilidad de uso que posibilita los terminales móviles.
    • Modelo de negocio: Publicidad, programa de afilición o incluso venta de la app.
  • Gametify
    • Spotify de videojuegos. Se autodescribe solo. Pagas una cuota mensual y puedes acceder a un catálogo de videojuegos.
    • Modelo de negocio: Pago por subscripción.

Los ganadores del Hackathon fueron 6-Games. Su idea, demo y puesta en escena fue muy buena (…y no falló nada :). Ganaron un fantástico tablet de BQ Reader cada uno. ¡Enhorabuena!

Nosotros, @sdelamo y un servidor como Devs, y @hugocamper, Francisco Díaz y Víctor Fabre , desarrollamos el PoC de Otogami App. La verdad es que para ser una iOS App de 1-day quedó bastante bien. A nivel técnico nos permitio experimentar nuevas tecnologías como Django REST Framework o las nuevas funcionalidades de iOS6.  ¡Gracias chicos!

Conclusiones

Quiero expresar mis impresiones y conclusiones sobre el 1º Hackathon DEV+BIZ

  • Sobre el tema, creo que hubiera sido más interesante propuesta que ayudaran a la venta de videojuegos de gran tamaño que se venden en tiendas físicas. Creo que la venta de juegos casuales o móviles, no tienen tanta necesidad de reinvención como los modelos tradicionales de venta de empresas como GAME, FNAC, etc.
  • Los tiempos de exposición fueron muy largos e irregulares provocando que la audiencia desconectara pronto. ¡Hay que sumar el día entero de trabajo a la capacidad de atención!
  • Para la presentación de modelos negocio usaria el Business Canvas Model. Sólo eso. Seria una forma unificada que todo el mundo usaria y entenderia. Algo así se podría hacer para explicar la parte Dev.
  • Creo que se hecho en falta gente de la industria IP como SCEE, Microsoft, GAME o Nintendo.
  • También eché en falta game philosophers como mis amigos de ArsGames.
  • Curiosamente no escuche la palabrota “gamification” en toda la jornada.
  • La jodida WiFi volvió a dar problemas en las DEMOS. ¿Lo solucionaremos algún día? Es como dejar a un cirujano sin bisturí teniendo el corazón del paciente abierto.
  • Todas las ideas me gustaron, pero no vi ninguna idea killer que ayude a vender más juegos.
  • Como siempre, el buen rollo reinó y “me lo pase como un enano” 🙂

Quiero agradecer a los organizadores,  @miquelcamps, @akey (Dani Rojo), @MarkVillaCampa y cia. por el gran trabajo que hicieron.

A título personal, muchas gracias a esos patrocinadores, Fon, bq readers, EDIS, MailJet, Generacion X y Red Bull, que ayudan a que estos geniales eventos sean posibles aún teniendo los presupuestos de marketing tan ajustados.

Los datos sobre los proyectos presentados los he sacado de mi mala memoria. Si hay algo raro o incorrecto, pls, comentadlo y lo corrijo o añado.

Ahora toca recuperar fuerzas para el 4º Hackathon (esperemos que no caiga en tan mala fecha ni coincida con otro hackathon como el de BlackBerry).

Bye!

Recursos

Face Alt, a Face alternative SaaS to detect faces in pictures in Beta

On July 7th I received an email from Face.com  where they said that their API will be off in 30 days.

That sucks! 

The reason of my anger was that Face.com provides a great free SaaS to detect and recognize faces in pictures and I and thousands of developers around the world use their API to run our applications. “Face” was acquired by Facebook a month ago and it seems that Facebook now only have access to this API.

I saw then clear: I will create a new open source alternative service. We’ll call Face Alt (http://face-alt.org).

After a hard week of work during free time, the Face Alt Beta is now online!

The main features of Face Alt are:

  • It’s open source. The repository is in GitHub. It uses the great open source library OpenCV.
  • Initially only been implemented frontal face detection. We use the Haar Cascade classifier. We need to improve the detection ratio.
  • Face recognizer will be availble soon. Probably we will use cv::FaceRecognizer (included in OpenCV). This library implements the Fisherface algorithm. Developed by Philipp Wagner.
  • Detection of gender or face attributes will be added using Fisherface too (probably)
  • Detection of rotated faces is under study.
  • If you want collaborate with us, join us in our google group: face-alt.
  • API is restricted to 100 requests per day maximum
  • JavaScript API library available. Python, Ruby, Java,C#…coming soon!

If you want to enter in the beta program, sign-up here.

About the SaaS implementation, we use a AWS server instance configured with nginx connected via FastCGI with a native C++ face detector implementation.

Finally, say we are looking for collaborators, if you like this exciting field of computer vision, come with us!

See you 🙂

Isobar Create London: nuestra primera app NFC, Pick&Drop

iPubs Team en Isobar Create London NFC

iPubs Team en Isobar Create London NFC

El penúltimo fin de semana de Marzo (24 y 25) tuvo lugar en Londres el 1º hackathon para el desarrollo de aplicaciones móviles que hacen uso de tecnología NFC en el viejo continente.

Anteriormente a Europa, se celebraron dos eventos en Estados Unidos (el primero en San Francisco y el segundo en Boston).

El evento fue organizado por Isobar (una agencia de comunicación moderna) en colaboración con una buena cartera de patners, destacando principalmente O2 (Telefónica UK). BlueVia, Google, Samsung, Kelloggs, Adidas, Kovio, etc.

La idea es sencilla, durante dos días y una noche te proporcionan la tecnología NFC, ayuda de expertos en la materia y un excelente catering para que equipos de hasta 5 profesionales (desarrolladores y/o diseñadores) creen una aplicación NFC que asombre al mundo.

El objetivo es claro, la tecnología NFC está ahí pero no se ha encontrado todavía un caso de uso que haga que las masas quieran ya un móvil con NFC. Los principales casos se que se conocen son: pagos, configurar el móvil según el contexto, cupones de descuento, intercambio de información entre terminales, etc. ¿Habrá que esperar a que Apple tome cartas en el asunto?

En las primeras horas del evento, recibimos charlas inspiradoras por parte de grandes profesionales de los respectivos patners. Así por ejemplo, habló el ingeniero jefe en NFC de Google, ingenieros de innovación de Proxama, el código ético de Diageo, etc.

Con las pilas de “innovación” cargadas nos pusimos manos a la obra. Ya teníamos la idea medio preparada y algunos diseños gráficos hechos.

Los criterios de evaluación iban buscando premiar aplicaciones que rompieran con lo visto hasta ahora, que establecieran relaciones marca-cliente, que ayudaran a retener la marca a los potenciales clientes y que tuvieran una clara explotación comercial.

Con estos requisitos la aplicación salió sola: “Pick&Drop“. Nuestra idea era crear un ecosistema de promociones representada por “chapitas” (badges). Es muy sencillo. Al tocar con tu móvil una tarjeta NFC “pick” obtienes la promoción. Cuando encuentras un punto “drop” puedes canjear dicha promoción.

Un ejemplo gráfico, en un revista ves un badge “pick” por una cerveza gratis. Pasas el móvil y lo capturas. Luego te acercas a tu bar o pub preferido, pasas el móvil otra vez y te ponen tu cerveza, ¿fácil no?

Esto se puede complicar para obtener premios mayores ya que hay promociones que requieren de más códigos. Ejemplo, si obtienes la chapita de la tónica y la chapita de la ginebra, puedes tomarte el gintonic perfecto. Con este mismo esquema se puede hacer un programa de fidelización del cliente, por cada 5 desayunos, 1 gratis.

Otro tipo de promoción que ideamos fueron las promociones para grupos. En este caso, el objetivo de la promoción es atraer a un grupo de amigos hacia una determinada marca, local, etc. Al pasar el móvil por una chapita de este tipo, verás qué amigos tuyos también lo tienen y podrás quedar con ellos para poder disfrutar de la promoción conjunta. Ejemplo, si vienes con dos amigos más a la pizzeria, os damos un pizza familiar gratis. Estas promociones se puede compartir a través de Facebook.

Volviendo al evento, el domingo a las 4pm se terminaba el hackathon y era el momento de presentar el “proof-of-concept” de la idea. Fuimos los primeros en exponer ya que teníamos que volver a casa pronto.

A pesar de que teníamos claro desde el principio que la presentación era clave, fue sin duda la peor presentación que he hecho en mi vida. Creo que nadie se entero de qué fue lo que hicimos. Hay que aprender de los errores para la próxima.

Los premios se dividían en 4 categorías:  retail (venta al por menor), entretenimiento y ocio, eventos deportivos y financiero.

Los ganadores de estas categorias fueron:

  • Retail: We’re Appy con “PillIt“, aplicación que permite llevar control sobre la medicación incluyendo un poco de gamification.
  • Entretenimiento y ocio: Blue Butterfly con “Tap-the-Wifi“, aplicación que permite configurar automaticante tu móvil para conectarte a lared wifi de bares, pubs, hoteles, etc. Ya existía una aplicación en Google Play que permite hacer esto y más cosas: NFC Task launcher
  • Eventos deportivos: Ying Yang con “Total Event“, aplicación para compartir información sobre jugadores durante un partido.
  • Financiero: New found comms con “Street Screen“, aplicación que permite hacer compras desde anuncios publicitarios.

Además de estos premios, habian otros 3 muy jugosos:

  • 10k £ para el desarrollo de la aplicación por parte de Proxama. El ganador volvió a ser “Tap-the-Wifi“. El jurado destacó su utilidad y sencillez.
  • Apoyo para el desarrollo de la aplicación por parte de BlueVía. El ganador fue Team Rollercoaster con una aplicación para reservar sitio en las colas de las atracciones de feria. Cuando tu turno se aproxima, te avisan.
  • Viaje con todos los gastos pagados a Blackberry World Conference en Orlando. El ganador fue London BBDG con “Tesco App“, aplicación que permite mejorar la experiencia de usuario de los compradores.

En líneas generales, parece que el jurado premió la sencillez. Felicidades a todos los ganadores.

Quiero agradecer a Isobar y a todos los patrocinadores por este gran evento que esperamos se replique por el resto de Europa. También añadir una crítica constructiva. La próxima vez que se convoque un evento, por favor, indicar la hora de finalización exacta. Nosotros tuvimos que cambiar la logística del viaje porque en un principio el evento terminaba antes de lo que al final fue. Una buena infraestructura Wi-Fi es muy recomendable (varias redes, baja potencia de emisión, canales ortogonales para que no existan interferencias,etc).

Agradecer también el apoyo que nos dió Andrés de BlueVia para integrar nuestra aplicación con su API.

El material NFC (tarjetas y lectores) que Taggito nos proporcionó fué también muy importante para prepararnos de cara al evento. Muchas gracias.

Ya estamos deseando acudir al próximo evento 🙂

Referencias:

Pantalla de inicio


Pick&Drop: splash screen

Captura de pantalla


Pick&Drop: Screen Capture

Tutorial Amazon Route 53

Tutorial Amazon Route 53

Tutorial Amazon Route 53

 

ACTUALIZACIÓN: (17/11/2011)  Amazon acaba de anunciar que ha incluido la gestión de Route53 desde la consola de gestión. Sin duda un gran avance que facilita enormemente la gestión DNS.

 

Amazon Web Services no para de sacar productos interesantes y económicos. Si las bases de datos se volvieron más simples con Amazon RDS, ahora “desaparece” el problema de la gestión DNS (más bien, se simplifica bastante) con Amazon Route 53.

Voy a explicar cómo podemos hacer un uso sencillo de Route 53 para nuestra pequeña web en nube. Vamos a suponer que tenemos corriendo una instancia de EC2 con la IP elástica 123.123.123.123.

A día hoy no se puede gestionar Route 53 desde la consola de AWS. Hay que recurrir a invocar directamente los servicios web mediante cURL.

Como ocurre en muchas ocasiones, la comunidad SL va por delante de las corporaciones y ya existe una utilidad CLI que nos permite operar con Route 53 de una manera más sencilla.

La utilidad se llama cli53 y ha sido desarrollada por bee11149. Lo primero que haremos será instalar tanto la utilidad como sus prerequisitos (Boto y dnspython).

git clone git://github.com/boto/boto && cd boto && python setup.py install
easy_install dnspython
git clone git://github.com/barnybug/cli53

En la primera línea instalamos Boto (Control de Amazon Web Services para Python).
Luego se instala dnspython y por último nos descargamos la utilidad cli53.

Para que funcione cli53, debemos establecer dos variables de entorno con nuestros credenciales de acceso a AWS.


export AWS_ACCESS_KEY_ID=<nuestra_clave_id>
export AWS_SECRET_ACCESS_KEY=<nuestra_clave_privada>
cd cli53

Ya esta preparado el entorno para empezar a usar cli53. Lo primero que haremos será crear nuestra hostedzone. Vamos a suponer que nuestro dominio es caramelos.com y queremos poder acceder a la web mediante “caramelos.com” y “www.caramelos.com”

./cli53.py create caramelos.com

Si todo va bien, nos debe devolver algo similar a esto:

HostedZone:
CallerReference: xxxxxxxx-8efb-4947-yyyy-53489dxxxxxxx
Config:
Comment:
Id: /hostedzone/Z2JZCX7IR3C3O9
Name: caramelos.com.
ChangeInfo:
Status: PENDING
SubmittedAt: 2010-12-21T10:16:05.719Z
Id: /change/C2JH25LA6TOVE9
DelegationSet:
NameServers:
- ns-739.awsdns-28.net
- ns-118.awsdns-14.com
- ns-1414.awsdns-48.org
- ns-1829.awsdns-36.co.uk

Esta información nos indica que se ha creado correctamente la hostedzone con ID Z2JZCX7IR3C3O9 (línea 5), que esta pendiente de sincronizar (8) y nos da
los servidores DNS a donde debemos apuntar el dominio (13-16).  Ahora debemos de contactar con el registrador de nuestro dominio “caramelos.com” y especificar estos servidores DNS.
Lo normal es que dejen establecer entre 2 y 4 servidores. A más servidores, mayor disponibilidad.

Por último, necesitamos crear las entradas DNS para que se pueda acceder a nuestra web. Recordemos que la IP del servidor donde tenemos nuestra web es 123.123.123.123.  Vamos a crear una entrada tipo A y otra CNAME. En formato BIND sería:

 

./cli53.py rrcreate caramelos.com @ A 123.123.123.123 --ttl 3600
./cli53.py rrcreate caramelos.com www CNAME caramelos.com --ttl 3600

Con la primera linea creamos un registro A que mapea nuestro dominio (caramelos.com, representado por @) a la IP 123.123.123.123, mientras que
con la segunda, asociamos el nombre http://www.caramelos.com a caramelos.com usando un registro CNAME. El parametro TTL (Time to live) sirve para indicar con
qué frecuencia se debería de refrescar la lectura de dicho registro por parte de clientes DNS.

Si todo ha ido bien, después de darle un tiempo para que se sincronice toda la cadena DNS, nuestro navegador web deberia mostrar la página si introducimos
caramelos.com” o “http://www.caramelos.com“.

Aquí podéis obtener más información sobre los distintos tipos de registros DNS.
¡A migrar DNS! 🙂