AWS: ¿repositorio imagenes?

bLaKnI

Buenas,

Veamos:

  • En el curro cambiamos de web. Se tira la vieja, nos crean una nueva.
  • Tenemos actualmente la web, en una instancia pequeña en AWS. Apache básico montado con PHP y algún bucket de S3 montado en dicha maquina para disco.
  • Esta web, tiene un alto contenido de imágenes (productos), pues es en realidad un eComerce. Toda estas imágenes están montadas en un sistema de directorios y se trabajan vía FTP. La web carga de ellas, lo que necesita.

Hasta aquí normal.

Ahora la nueva web, gestionará las imágenes a su manera. No es necesario entrar en ello.
Pero se quiere montar un repositorio de imágenes único, en el que se suban todas las imágenes de la empresa que se requieran ahí, y solamente ahí.
Y la nueva web, bebería de ello, así como scripts, y demas cosas que puedan haber. Al final, todas las imagenes irian a buscarse a traves de "http://imgs.tralalalalala.lol/imagen_1_l.jpg, por ejemplo.

¿Como monto esto? ¿Cual es la mejor solución?

  • Instancia pequeña en AWS con un bucket S3 montado como disco primario, con servicios FTP y puertos levantados, y con un Apache activo, con certificado ssl para el subdominio imgs.tralalalalala.lol, para que pueda pedir desde un browser por ejemplo, la url de la imagen?
  • Lo anterior, pero con AWS Elastic Beanstalk?
  • ¿Sistema AWS Transfer Family?
  • ¿Levanto una imagen AMI en AWS de CPanel por ejemplo?

¿Que se os ocurre?

Thanks.

Mujiwara

Puedes utilizar CloudFront + S3 para servir todo el contenido estático que necesites, si solo necesitas que se suban ahí y no haya control de restricciones no hace falta montar nada más, al nuevo eCommerce le pones la API de S3 a la hora de subir archivos y con CloudFront haces que se pueda acceder a través del subdominio/dominio que necesites a ese bucket

2 1 respuesta
isvidal

Dejaos de soluciones in-house:

http://cloudinary.com/

1 respuesta
D

CloudFront + S3 para todo el contenido estático. Y por dios, no monteis el bucket de S3 como un volumen en una instancia, es cutre y contraproducente.

2 respuestas
PiPePiTo
#4DiSKuN:

CloudFront + S3 para todo el contenido estático.

Basicamente, si es para alojar imágenes y luego cargarlas... tiras de esto, rápido, sencillo y en todos lados.

1 respuesta
bLaKnI

#3 Parece interesante, pero veo que no puedo asociar las imagenes contra un subdominio de mi TLD. Solo en ADVANCED plan te lo permiten (que se va a los 230 pavos al mes) y no es directo, sino algo del tipo "misubdominio-cloudinary.com" lo cual es pastel... ¿lo leo mal? ¿Para uso basico de subir cosas al ftp que te den y mostrarlas por url estatica, bien?

#2 #4 #5 Cloudfront + s3. Parece genial una CDN, no lo habia pensado... Buena manera de explotarlo! :)
Entonces, siendo nuevo en la materia para este caso, algun tuto bueno que seguir? Quisiera esta solución, pero con dominio (subdominio en realidad) propio asignado.

Que tal con esto:

https://aws.amazon.com/es/blogs/networking-and-content-delivery/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/

en el "STACK A" (ya que sería cuenta cloudfront nueva y bucket s3 nuevo) y esto:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html

para la asignación de mi dominio como alternativo?
Creo es el camino no?

Ideas de presupuesto? que cuesta esto mensualmente aprox? Esta solución?

Thanks!!

1 respuesta
JuAn4k4

#6 Depende de la transferencia, no es barato si tienes mucha. Y también depende de la cantidad de edges en los que pongas el CDN. Hay calculadoras pero necesitas saber la transferencia mensual que esperas.

1 respuesta
bLaKnI

#7 Vamos a suponer, que un shooting de producto se hace una vez al mes. Y por cada shooting hay que subir al FTP unas 1500 fotos. Por FTP.
Luego las imagenes se cargan en la web como tal, y en algunos scripts que las muestran, así como embedidas en algunos programas por ser llamadas directamente contra URL.
Por transferencia mensual que quieres decir? Requests o transito de cargas en FTP? Ambas?

Aqui:

https://aws.amazon.com/es/cloudfront/pricing/

Ponen que en Europa, las primeras 10TB, el precio por GB de movimiento de datos, es de 0.085USD? Pero esto no es caro... es regalado. O algo hago mal?

Luego por 10k solicitudes HTTPS, en Europa 0.0120USD, es decir, que si 10k veces me van a https://imgs.trlaalallaa.com/imagen234.jpg o cualquier otra, a las 10k aperturas de imagenes, me cobran 0.0120USD?

Si esto es así, vamos sobradísimos según creo... Si en un dia llegaran a abrirme 1 millon de imagenes en general, me cobrarian 1.2€!

1 respuesta
D

#8 Se refiere a tráfico. Usuarios accediendo al CDN para visualizar las imagenes que están en S3 subidas

1 respuesta
bLaKnI

#9 Usando:

https://calculator.s3.amazonaws.com/index.html

Me sube a 219$/mes, si configuro en Irlanda un S3 de 1TB, con una transferencia IN de 1TB al mes y una out de 1TB al mes igual.
Y luego con CloudFront, muevo 1M de peticiones HTTPS con un trafico de 1Tb in y out y marcando que la media de tamaño por articulo es de 1024Kb (1MB, que seguro que no, pero voy a mayores). Y con esta config, los 219$/mes.

Esto sería mucho trafico? Lo estoy haciendo completamente chupando el dedo.

1 respuesta
D

1 TB de imágenes? Pero que vas a meter ahí? es una animalada de datos xD

JuAn4k4

#10 Si usas browser caching y los que acceden son pocas personas bien. Si acceden muchas personas diferentes la cosa cambia:

Numero de usuarios medios al mes * número de imagenes (nuevas) que descargan/ven cada usuario de media al mes * tamaño medio de imagen = transferencia mensual. O haces la media diaria si es más fácil y *30

La web imagino que será poca cosa.

bLaKnI

Acabo de acabar AHORA mismo, a las putas 5.24 de la mañana, de montarlo todo. Llevo casi todo el dia con ello...
De trivial decíais? Mis cojones 33!

Ahora si, ya soy un puto experto de AWS... xD
Menuda maratón y menudo intensivo macho...

1 respuesta
D

El problema con AWS y similares, és que al inicio ha de leer mucha docu. És normal tardar tanto la primera vez

1 respuesta
JuAn4k4

#13 Has hecho un resumen de lo que has hecho ? Verás que en realidad has hecho pocas cosas, lo que cuesta es saber qué cosas hacer y cómo. Seguramente no habrás añadido ni tags a las cosas.

Recuerdo cuando aprendí como iba Fargate, igual cree el cluster 8 veces, junto con sus load balancers, tasks, vpcs, security groups, etc.., las 2 primeras veces les puse los tags, luego le dieron por culo hasta que lo hice bien y lo puse con terraform. Es un puto horror cuando tienes todo y ves que para hacer blue-green deployment, tienes que hacerlo desde el principio diferente, y no puedes editarlo, borrar todo y volver a crear.

1 respuesta
bLaKnI

#14 #15 Ni mas, ni menos.
Si, gracias a dios lo documenté todo. Es decir, me dediqué a realizar un tutorial como si supiera que hacía! Y iba borrandolo y reescribiendolo todo el rato! xD

Un puto suplicio. Pero es cierto que ahora ya lo haría mas rapido.
Si pues tags, las primeras veces... y luego como dices, le dieron por el culo! xD

Claro, la cosa va tal que así:

  • Empece con un stack precreado de Cloudformation, que hacía un deployment de un bucket S3, con cloudfront y con un cert SSL desde ACM.
    Nada. Lo desplegue infinitas veces, y en todas falló en algun punto. No habia manera. Rollback y volver a empezar, Y ir borrando a mano los buckets, etc...

Por lo que al final la cosa queda tal que:

  • Gestor de DNS fuera del Route53 para TLD principal.
  • Creo en Route53 un hosted zone para el subdominio, y en el gestor de Arsys, delego mediante los 4 registros NS de turno con los servers de Amazon.
  • Luego creo el bucket. Lo hice publico desbloqueando, y luego añadiendo la policy correcta y el ACL pertinente (que no encontré como escribirlo via XML con los <grants> y tuve que hacerlo seleccionando en el bucket el Public Acces y dando permiso de "listar" (que es READ).... ojo con las traducciones al español de AWS macho...
  • Lo siguiente, cloudfront para ALL EDGES contra el bucket (que previamente estaba ya habilitado para static web pages), con redirect de http a https i con certificado personalizado.
  • Para el certificado, se crea normalmente, se añade la entrada en Route53 y a correr. Ya queda validado el dominio (el subdominio) y por lo tanto te lo EMITEN.
  • Se puede ya asociar al cloudfront. Además, es importante marcar el DEFAULT ROOT OBJECT en cloudfront porque sino, cuando accedes via https, te salta el directorylist en XML...
  • Una vez creado y deployed, en Route53, hay que crear un par de entradas A y AAAA para ip4 y ip6 que redirigan como ALIAS al servicio de cloudfront el subdominio. Y con esto ya se corre mas o menos.

Luego viene la puta locura del IAM. Crear un usuario para trabajar que esto es lo que mas me costó, porque no habia manera de que cuadraran las cosas.
Añadi en el bucket, una politica de s3:Listbucket para el usuario y un s3:* para las acciones del usuario en bucket/*
porqure si añadia las individuales clasicas put, get y delete, no funcionaba... :\
Luego en el usuario, una policy directa homologa de listbucket para el que toca, y de s3:* para las acciones contra el bucket/*. Y con esto ya pude currar.

La sorpresa final fue con WinSCP, que no habia manera de conectar. Y esas son 2 cosas curiosas:

1) El usuario tiene solamente politica de acceso al Bucket. Nada mas. En cambio, puede loguear en la consola con id (12 numeros IAM) y hacer muchas cosas! Otras estan capadas, pero en otras puede acceder! Y cuando va al s3, y deberian listarse los buckets (o al menos, solamente el suyo que tiene acceso) aparece PERMISION DENIED! Joedete! Asi que si quiera que alguien se loguee en la consola de AWS con este IAM espcifico creado para trabajar con el bucket (a efectos practicos, un usuario FTP lo llamariamos), no puede. No ve su bucket siquiera...

2) Y en WinSCP no habia manera, hasta que di con un tuto de un pavo en inet, que decia: en advanced conection, vete a Directories i pon entre "/" el nombre de tu bucket!
Entonces te queda tal que /nombre_del_bucket/, y con eso CONECTA!!!

Jodete patrón...

Alguna idea de como hacer para ver el bucket en la consola de S3?

bLaKnI

Vale creo que acabo de ver que cojones pasa...

https://aws.amazon.com/es/premiumsupport/knowledge-center/s3-console-access-certain-bucket/

Le creas las policys como se espera, pero si pretendes que el tio vaya a los sitios navegando como el usuario raiz, estas muerto. Hay que darle el puto link directo al repo. Lo que es igual que con lo que sucede en WinSCP. O le das el "endopoint" final, o no entras. Muy curioso... pensaba que sería nativo el acceder por la vía natural hacia el punto al que tienes permiso...


Y ESTO!!!
Acabo de encontrarlo en STACK:

https://aws.amazon.com/es/premiumsupport/knowledge-center/s3-console-access-certain-bucket/


Ves... es agotador. A medida que vas buscando y buscando en internet, encuentras mas y mas material...

Creo que el definitivo es este:

https://docs.aws.amazon.com/AmazonS3/latest/dev/walkthrough1.html

Creo se podria hacer un mix... Pasaria de la politica de grupo, y seguiria con una directa de usuario, pero añadiendo el s3:GetBucketLocation

1 respuesta
wdaoajw

#17 todas estas chorradas son las que luego particularizan a la gente que se especializa en cloud (devops/arquitectos) ya que tienen una forma de trabajar y hacer las cosas diferentes aa infraestructura clásica de CPD

Por cierto, como apunte, si el desde donde accedes a las imágenes está hosteado en AWS, puedes añadirle un rol a esa EC2 para no necesitar credenciales de acceso al bucket

2 respuestas
D

#18 de hecho, se recomienda roles antes que usuarios IAM si quien ha de acceder, ha de ser otro recurso de AWS

1 respuesta
bLaKnI

#18 #19 Gracias a ambos!
en la web antigua si estaba así. La EC2 levantada con la web de prod, accedia al bucket a consumir, de hecho, lo montaba como volumen.

Ahora la web estará a saber... En teoria, esta gente lo monta todo en AWS también, por lo que se podría crear una policy con cruce KMS... pero sería rizar mucho el rizo, aunque facilitaría las cosas...
En cualquier caso el bucket es nuestro y lo gobernamos nosotros, y el "host" con la web/oscommerce es suyo y lo gobiernan ellos en sus VPCs.

1 respuesta
D

#20 en ese caso solo te has de preocupar que el bucket acceda quien haya que acceder y con los permisos correspondientes

P.D: tagea todo. És buena praxis para luego buscar el recurso concreto

Usuarios habituales

  • DiSKuN
  • bLaKnI
  • wdaoajw
  • JuAn4k4
  • PiPePiTo
  • isvidal
  • Mujiwara