¿Cómo pueden todos configurar AWS para PHP con un flujo de trabajo git mientras se preocupan por distribuir EC2?

¿Cómo pueden todos configurar AWS para PHP con un flujo de trabajo git mientras se preocupan por distribuir EC2?

He estado buscando algo como heroku pero para php, y después de mucha frustración (y casi encontrando lo que necesito, pero no del todo) decidimos optar por AWS sin ninguna otra abstracción.

Estamos usando PHP 5.3 (y CakePHP 1.3) y actualmente usamos git. Ubuntu parece ser la forma más fácil de incluir ambos y lo más probable es que lo usemos. Realmente no vamos a preocuparnos por el correo electrónico saliente. Estamos usando smtp a través de Gmail, pero lo más probable es que eventualmente cambiemos a algún otro servicio.

Tenía 3 preguntas:
1) He estado mirando Zend Server y no estoy muy seguro de por qué es más beneficioso que xampp. ¿Quizás no lo sea?

2) Supongo que para escalar la aplicación necesitaríamos varias instancias de alguna ami ec2. Luego simplemente duplícalo y tal. La pregunta entonces es ¿cómo nos aseguramos de que todas las instancias EC2 estén actualizadas?

3) Entiendo el concepto de equilibrio de carga hasta cierto punto. Entiendo que en 1 región seleccionas un grupo de servidores y haces que la carga se equilibre entre ellos. La pregunta entonces es: ¿qué tal en todo el mundo? ¿Cómo hago para que el tráfico se dirija al servidor ec2 correcto? Escuché sobre la ruta 53 e intenté registrarme, pero no aparece nada en mi panel de control. Además, ¿tal vez sea solo una cuestión de DNS con el registrador de mi dominio?

AHHH... ¡algún tutorial sería útil!

Respuesta1

1, ¿Qué quieres decir con más beneficioso? Por favor haga una pregunta más explícita.

2, tienes muchas opciones. Use cualquier control de versión y extráigalo, genere una nueva AMI cuando tenga una nueva actualización e inicie una nueva instancia y demuele las antiguas, descargue torrents y distribuya su aplicación con Facebook o Twitter. El sistema operativo actualizado es trivial (al menos debe serlo para cualquier distribución de Linux)

3. Obtiene una IP elástica en cada región en la que le gustaría estar (Europa, SF, Singapur, etc.) y configura una solución GeoDns donde la respuesta (IP) a la consulta DNS depende de la IP de origen del solicitante, por lo que alguien de Alemania obtiene la IP de la UE, alguien de Kansas obtiene la de Virginia, etc. Dado que el uso del equilibrio de carga elástico no es obligatorio, tiene muchas opciones, como usar su solución de equilibrio de carga o proxy inverso, lo que prefiera.

Puedes contactarme si necesitas más ayuda con este tema.

información relacionada