domingo, 31 de diciembre de 2017

Usa CodeLabs para aumentar tu experiencia

En google cloud español publicado en 2017 dic 31 por Guillaume Laforge

No hay nada mejor que la experiencia práctica: aprende algo de la tecnología Google Cloud practicando con codelabs

Obtenga experiencia práctica con Google Cloud Platform


En la víspera de un nuevo año, probablemente estas ocupado celebrando con amigos y familiares, pero mientras se prepara para el nuevo año, planeando sus buenas resoluciones, es posible que esté pensando en obtener experiencia práctica con Google Cloud Platform. Ayer, hablamos sobre los tutoriales de Google Cloud Community, para comprender cómo aprender sobre la plataforma siguiendo los tutoriales. ¡Hoy vamos a hablar sobre Codelabs! Practicar es definitivamente la mejor manera de aprender, y recuerda a largo plazo lo que has descubierto.

Afortunadamente, para ayudar con la experiencia de aprendizaje práctico, ¡puede aprovechar Google Codelabs!

Hay toneladas de codelabs disponibles a lo largo de diferentes temas, tales como:

A veces, un conjunto particular de codelabs también se recopilan para eventos específicos, por ejemplo, durante la conferencia Devoxx Belgium 2017, donde el equipo de Google Cloud Platform presentaba desafíos de codificación en su stand.

Algunos ejemplos de codelabs:

Construyendo un servicio gRPC con Java
Implementar Spring Boot Application en App Engine estándar
Detectar etiquetas, rostros y puntos de referencia en imágenes con la API de Cloud Vision
Crear una base de datos MySQL administrada con Cloud SQL
Introducción Istio con Kubernetes

¡Es hora de empezar!
________

sábado, 30 de diciembre de 2017

¿Que sabes acerca de los tutoriales de la comunidad de google cloud?

Ahora en google cloud español publicado en 2017 dic 30 por Guillaume Laforge

Siga los tutoriales de la comunidad para aprender a aplicar recetas concretas


Toneladas de interesantes tutoriales con recetas concretas aplicadas a Google Cloud Platform

¿Quieres aprender a ...


Bueno, para todas esas tareas y más, hay tutoriales aportados por la comunidad disponibles.


Puede buscar tutoriales por palabras clave en la interfaz de usuario Y esos tutoriales también están cubiertos en la búsqueda de documentación cuando hablamos sobre la búsqueda fácil de soluciones y tutoriales.
¡También es posible solicitar nuevos tutoriales, así como enviar los tuyos propios!

________

viernes, 29 de diciembre de 2017

Usando registros de "Containers" entre distintos proyectos


Comparta el mismo "Container Registry" en diferentes entornos GKE.

En la mayoría de las organizaciones, es una práctica común administrar las imágenes de Docker en un solo espacio de nombres, como Google Cloud Project o AWS.

Este proyecto dedicado de CI / CD en la nube crea, pushes, prueba imágenes de Docker e implementa continuamente nuevas versiones de imágenes en cada entorno de Google Kubernetes Engine.

Esos entornos se aprovisionan en proyectos separados, como desarrollo, puesta en escena y producción.

Con Container Builder o cualquier otro elemento de configuración como Gitlab CI / CD o Circle CI, por nombrar algunos, se puede utilizar para fines de CI / CD.

Una pregunta interesante es cómo un clúster GKE de cada entorno puede hacer un pull docker imágenes  desde un mismo proyecto de CI / CD.

El consejo: otorgar objectView en  Cloud Storage que alberga las imágenes del contenedor Docker.

Otorgar acceso a otro proyecto

Digamos que el clúster GKE del proyecto coolgig-dev necesita obtener una imagen Docker de ElasticSearch, como por ejemplo: http://gcr.io/coolgig-cicd/elasticsearch:6.1.1

De acuerdo con la documentación sobre el control de acceso para Container Registry, GKE, de forma predeterminada, utiliza la cuenta de servicio de cálculo de recursos, es decir <project-number> -compute@developer.gserviceaccount.com, donde <project-number> se puede encontrar a través de:

gcloud projects describe coolgig-dev --format='value(projectNumber)'
A continuación, podemos otorgar la siguiente función objectView del siguiente depósito GCS a la cuenta de del entorno de "compute-engine" para  coolgig-dev.

gsutil iam ch \
serviceAccount:<project-number>-compute@developer.gserviceaccount.com:objectViewer \
gs://artifacts.coolgig-cicd.appspot.com
Y ahora puede extraer una imagen del CI / CD GCR en su proyecto de entorno de desarrollo, aunque proviene de un proyecto de GCP diferente:

gcloud config set project coolgig-dev
gcloud docker -a
docker pull gcr.io/coolgig-cicd/elasticsearch:6.1.1
________

Securizando por defecto la implementación de App Engine

En google cloud español publicado en 2017 28 de diciembre por Laurent Picard

Para su aplicación web, una buena práctica es asegurarse de que todas las solicitudes se manejen a través de HTTPS de manera predeterminada. Esto se puede configurar fácilmente para todas las URL en el archivo de despliegue:


Redirección HTTP → HTTPS para Python / Go / PHP


app.yaml



secure: always
redirect_http_response_code: 301


  • La primera línea actualiza todas las solicitudes HTTP a HTTPS con una redirección 302.
  • La segunda línea lo convierte en una redirección 301 permanente (guardable en caché por el navegador y amigable para SEO).

Ejemplo para un sitio estático


...
  handlers:

  - url: /
    static_files: www/index.html
    upload: www/index.html
    secure: always
    redirect_http_response_code: 301

  - url: /
    static_dir: www
    secure: always
    redirect_http_response_code: 301



Redirección HTTP → HTTPS para Java


web.xml


<security-constraint>
    <web-resource-collection>
        <web-resource-name>HTTPS redirect</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

  • Esto actualiza todas las solicitudes HTTP a HTTPS con una redirección 302.
  • Al usar las anotaciones de @WebServlet, web.xml es opcional y es posible que deba crearse.

Más información

    App Engine
    301 redirección

Nota

Esta es una forma sencilla de proteger su aplicación web, pero existen otras mejores prácticas más avanzadas, como HSTS. ¿Hay espacio para consejos adicionales?

miércoles, 27 de diciembre de 2017

Busque vulnerabilidades en sus contenedores docker


Hoy hablamos en google cloud español del escaner automáticamente las imágenes de Docker en su repositorio de Google Cloud en busca de vulnerabilidades conocidas.

La seguridad es crítica para sus aplicaciones. Al usar contenedores, ¿cómo se asegura de que reduzca el área de superficie de ataque? ¿Cómo estar seguro de que su sistema operativo y sus paquetes son lo suficientemente recientes y no se ven afectados por vulnerabilidades no cubiertas?


Bien, si almacena su contenedor imagina en Google Cloud Registry, es una buena opción aprender sobre esta característica alfa: Escaneo de vulnerabilidad de registro de contenedor de Google. La API de análisis de contenedores admite la exploración de vulnerabilidad de paquetes para imágenes basadas en Ubuntu, Debian y Alpine.


Vamos a configurar el escenario

A los fines de este consejo, creé una imagen de contenedor pequeño para ejecutar un script de Apache Groovy simplemente imprimiendo hello world:


FROM groovy:alpine
ADD hello.groovy ./
CMD ["groovy", "hello.groovy"]
Construí mi imagen:

$ docker build . -t hello
Sending build context to Docker daemon  3.072kB
Step 1/3 : FROM groovy:alpine
alpine: Pulling from library/groovy
2fdfe1cd78c2: Pull complete 
82630fd6e5ba: Pull complete 
119d364c885d: Pull complete 
287ef2aa8ecb: Pull complete 
fe31a0044ad1: Pull complete 
Digest: sha256:60fc6fdb148c2a5c48989d384e56d19bd288151b6d82770bb2f7d42674b9da0f
Status: Downloaded newer image for groovy:alpine
 ---> 34ce9830b507
Step 2/3 : ADD hello.groovy ./
 ---> 96a805f80806
Step 3/3 : CMD groovy hello.groovy
 ---> Running in 78040114c799
 ---> 467a80cf4614
Removing intermediate container 78040114c799
Successfully built 467a80cf4614
Successfully tagged hello:latest
Y etiquetado:

$ docker tag hello gcr.io/docker-vulnerability-scanning/hello
Solo para asegurarme de que todo estaba bien, verifiqué dos veces que mi mensaje se imprimió correctamente:

$ docker run -it hello
Hello Groovy world!

He habilitado la API de registro de contenedores:



"Push" a la imagen al registro:

$ gcloud docker -- push gcr.io/docker-vulnerability-scanning/hello
The push refers to a repository [gcr.io/docker-vulnerability-scanning/hello]
3e84e885bf33: Pushed 
baeea7770e60: Pushed 
e2468806cd9c: Pushed 
25baa3ba1903: Pushed 
5b1e27e74327: Pushed 
04a094fe844e: Pushed 
latest: digest: sha256:0ed6cbc3ec3e3ef6a25ffd4f82c8092ff8ee994f4be89dcbe89fbd33cc842860 size: 1573
Ahora mi imagen está en el Registro de contenedores:
Verificando que la imagen del contenedor esté cargada

Habilitando el escaneo de vulnerabilidad

Nota: Como todavía es un servicio alfa, deberá estar en la lista blanca para poder habilitar la API. Puede activar la API de análisis de contenedores solo si su dirección de correo electrónico está incluida en la lista blanca para usar esta API. Si está interesado en probar esta nueva característica, únase al grupo de Usuarios de análisis de contenedor para inscribirse.

En primer lugar, debemos habilitar API de Container Analysis visitando esta URL y seleccionando nuestro proyecto de Google Cloud:


Luego, vaya a la página de configuración de GCR, active la función de exploración de vulnerabilidad:




Después de un momento, cuando el escáner recorre las imágenes de su contenedor, debería ver que ejecutó su análisis:


Si hace clic en el resumen de vulnerabilidad, podrá ver el informe detallado (en mi caso, estoy contento, no se encontraron vulnerabilidades):



Más información

El consejo se inspiró en un artículo de David Gageot sobre escaneo de vulnerabilidades en imágenes Docker, que también muestra algunas capturas de pantalla de informes de imágenes de contenedores que contienen vulnerabilidades.
Además, lea más acerca de esta nueva característica alfa: Escaneo de vulnerabilidades del Registro de contenedores de Google

martes, 26 de diciembre de 2017

Localiza tu versción de google cloud SDK

Publicado en 2017 dic 26 por Javier Lopez

En google cloud español al desarrollar aplicaciones frontend con Javascript que luego se implementarán en Google App Engine, se recomienda encarecidamente utilizar gestores de paquetes como NPM.

NPM no solo nos ayudará con los paquetes Javascript, sino que también se encargará de facilitarnos la vida con el despliegue de nuestra aplicación.

Si esta es la primera vez que se utiliza NPM, cuando intentamos ejecutar una implementación localmente (con npm run devserver) o en producción en App Engine (con npm run deploy), arrojará un error porque la variable GCLOUD_SDK no está definida.

Para evitar que esto suceda, de antemano, debemos especificar la ruta en la que se encuentra Google Cloud SDK. Sin embargo, a veces tenemos varias versiones del SDK en diferentes directorios y no sabemos con certeza qué versión está siendo utilizada cuando llamamos al comando gcloud.

Para solucionar este problema, hay un comando muy simple que siempre devuelve la ruta correcta:

gcloud info --format="value (installation.sdk_root)"
Una vez que se obtiene el directorio, solo tendremos que anexar /bin al final, exportarlo, y luego podemos ejecutar el comando deploy:

export GCLOUD_SDK=/home/user/example/google-cloud-sdk/bin
npm run deploy

Registrarse en la prueba gratuita de Google cloud

Publicado en 2017 dic 25 por Guillaume Laforge

En google cloud español use Google Cloud Platform de forma gratuita con la versión de prueba gratuita y la versión gratuita

Por que no celebrar la Navidad hoy, es un gran momento para regalar presentes a sus amigos. Mi regalo para aquellos que no están familiarizados con Google Cloud Platform es este consejo sobre ... ¡la versión de prueba gratuita de GCP!

Bueno, en realidad, hay dos aspectos que me gustaría cubrir:

  • La prueba gratuita en sí, así como
  • La fórmula Always Free.


Prueba gratis

Con la versión de prueba gratuita, cuando se registra en Google Cloud Platform, obtiene un crédito de $ 300 por 12 meses.

Así que tiene mucho tiempo y suficientes créditos para probar los diversos productos y servicios que ofrece la plataforma.

Fórmula siempre gratis

Además de esos créditos, varios productos y servicios en realidad ofrecen una cuota gratuita, que le permite ejecutarlos para siempre, siempre y cuando se mantenga por debajo de esos niveles de cuota.

Por ejemplo, de forma gratuita, puede:
  • Ejecutar aplicaciones de App Engine con Datastore (28 horas de instalador frontend por día, 5 GB de almacenamiento en la nube, 1 GB de espacio de almacenamiento de datos ...)
  • Ejecutar una instancia de Compute Engine f1-micro de forma gratuita durante un mes
  • Envíe 1GB por mes de mensajes en Cloud Pub / Sub
  • Invocar 2 millones de funciones en la nube al mes
  • Ejecutar 1TB de consultas de BigQuery al mes y almacenar 10 GB de datos
  • y más…

Más información

Obtenga más información sobre la versión de prueba gratuita y el nivel gratuito.

Eche un vistazo a este video de Cloud Minute sobre cómo registrarse para la versión de prueba gratuita:


O este otro en Español:


Aprende de google Cloud con videos de un minuto

Publicado en 2017 dic 24 por Guillaume Laforge

En google cloud español con los videos de Cloud Minute, puedes aprender algo nuevo sobre GCP



En este canal, tienes consejos en videos consejos son muy cortos para que pueda aprender algo nuevo y útil, en un tiempo mínimo, ¡de manera que pueda pasar rápidamente a su próximo artículo pendiente!

¡Este es también el propósito de los videos de Cloud Minute! En los videos de Cloud Minute, aprenderás algo nuevo, visualmente, en 60 segundos, ¡ni más ni menos!

Por ejemplo, echemos un vistazo a algunos de los videos existentes:



¡Y hay mucho más videos de 60 segundos de duración para mirar!

Contenido estatico publicado en Cloud Store

En google cloud español Publicado en 2017 dic 23 por Guillaume Laforge

Hacer público el contenido estático almacenado en Google Cloud Storage públicamente


Cuando necesite publicar contenido rápidamente en la web, hay muchas opciones disponibles. Es posible que su ISP le ofrezca algún espacio web, podría usar los millones de servicios en la red (como plataformas de blogs o soluciones CMS). Pero también puedes usar Google App Engine o Firebase. Sin embargo, en este consejo, hoy vamos a considerar almacenar un sitio web estático o recursos estáticos para sus aplicaciones móviles en Google Cloud Storage.

Almacenamiento de contenido en GCS

En nuestro primer consejo, hablamos sobre cómo cargar contenido más rápido en un segmento de GCS. Usamos la interfaz de línea de comandos gsutil, usando el indicador -r, con el sub comando de cp para copiar los archivos de nuestro sistema de archivos local al contenedor.

También puede usar la consola de la nube web para cargar contenido desde su navegador web. Cuando se encuentre dentro de la consola, en la sección Almacenamiento en la nube, debería ver botones para cargar archivos o cargar una carpeta.

Haciendo los recursos públicos

Desde la consola web, hacer públicos los recursos está a un clic de distancia. A lo largo de sus recursos, verá una casilla en la columna compartir públicamente, que hará que su activo sea público. Una vez que hace clic, incluso obtendrá un enlace a la URL pública del activo publicado:



Cargar recursos y publicarlos en una línea

Como se trata en este artículo de Valentin, puede subir y hacer públicos sus recursos en una sola línea:

gsutil cp -r -a public-read my-assets/* gs://my-bucket/

En particular, tenga en cuenta la parte  "-a public-read" que hace públicos los recursos de una vez.

Punto de bonificación
Si desea tener una URL más amigable, puede considerar usar su propio nombre de dominio, en lugar del prefijo  https://storage.googleapis.com/ . Puede leer más sobre esto en la documentación sobre Hosting de un sitio web estático en Cloud Storage.

viernes, 22 de diciembre de 2017

"Entities" compuestas con Dialogflow

En google cloud español Publicado en 2017 dic 22 por Guillaume Laforge

Localizando  valores complejos gracias a entidades compuestas

Cuando se construyen interfaces conversacionales, necesitamos localizar los patrones complejos.

Dialogflow viene con varios tipos incorporados (normalmente llamados entidades del sistema system-entties), para reconocer varias formas de: fechas y horas, números (ordinales, cardinales o incluso números al vuelo), cantidades y unidades (como distancias, monedas, duración o temperatura), nombres de unidades, geografía (direcciones, códigos postales, códigos de aeropuertos, y más), así como nombres (incluso artistas de música).

Pero a veces, necesita su propio tipo de entidad, para que coincida con algo que es específico para su caso de uso.

En el ejemplo desarrollado a continuación, defino una entidad entity especial que representa un movimiento de robot: que es la combinación de varios pasos y una dirección. Y Dialogflow me permite definir dicha estructura, para que coincida como una entidad distinta dentro de mis intenciones.

Los usuarios de mi chatbot deberían ser capaces de dar órdenes a mi robot, y decirle que mueva un cierto número de pasos, en una dirección particular, como esta:


Primero, vamos a crear una entidad  entity de dirección, que cubre las 4 direcciones principales (incluidos algunos sinónimos): adelante, atrás, izquierda y derecha:


Luego, podemos crear nuestra entidad compuesta de movimiento, que combina una serie de pasos, la palabra paso y nuestra dirección recién creada:


Ahora, sus intents  pueden hacer referencia a esta entidad @move para que coincida con los movimientos complejos que no formaban parte de las entidades integradas en Dialogflow.

Feliz navidad y prospero cloud año


Os desemos una feliz navidad y un año de mucho Cloud

jueves, 21 de diciembre de 2017

Google cloud KMS en acción

En google cloud en español Publicado en 2017 dic 21 por Victor Yang

Descubramos Google Cloud KMS en acción para almacenar y compartir un secreto


Para el consejo de hoy, vamos a echar un vistazo a Google Cloud KMS: el Servicio de administración de claves proporcionado por GCP. Presentaremos un caso de uso concreto y veremos cómo usamos KMS para almacenar y compartir nuestro secreto.

Como lo usamos

Secretos como la cuenta de servicio de Google JSON, clave y secreto de AWS, ID de base de datos y contraseña, etc., se pueden cifrar y descifrar fácilmente con Google Cloud KMS. Cloud KMS no almacena secretos directamente. Puede encriptar los secretos que almacene en otro lugar, es decir, la clave misma se almacena dentro de KMS.

Vamos a ilustrar con un ejemplo del mundo real paso a paso. Podemos cifrar y descifrar un archivo JSON de la cuenta de servicio para las instancias de Google Compute Engine. Estas instancias son parte de un clúster de ElasticSearch. El administrador de Google Cloud crea la cuenta de servicio. Terraform utiliza la cuenta de servicio para aprovisionar las instancias de cómputo como se muestra aquí.

Los desarrolladores quieren una copia del archivo JSON de la cuenta de servicio para que puedan desarrollar y probar con el clúster ElasticSearch. El administrador de Google Cloud crea el archivo JSON del servicio de texto sin formato, ¿dónde y cómo almacenarlo de forma segura? Almacenar en la computadora portátil del administrador no es 100% seguro. Estos son los pasos que aprovechan Cloud KMS en su lugar.

Nota: para simplificar, no vamos a hablar aquí sobre la rotación de llaves.


Crear un llavero

gcloud kms keyrings create dev_keyring --location global

Crea una clave


gcloud kms keys create sa --location global \
       --keyring dev_keyring --purpose encryption
El comando anterior crea una clave SA para encriptar el archivo json de la cuenta de servicio de google.

Cifrado

gcloud kms encrypt --location=global --keyring=dev_keyring --key=sa \
       --plaintext-file=elasticsearch_svc_account.json \
       --ciphertext-file=elasticsearch_svc_account.json.enc
En este punto, podemos eliminar el archivo de texto sin formato elasticsearch_svc_account.json de la computadora portátil.


Almacenamiento


export GOOGLE_PROJECT=$(gcloud config get-value project)
export ENV=dev
gsutil cp elasticsearch_svc_account.json.enc gs://${GOOGLE_PROJECT}-secrets-${ENV}/
Dónde almacenar los sercretod cifrados? Se pueden almacenar en un depósito GCS o en cualquier almacenamiento de datos del sistema de configuración gestionada, como una Bag-data-Chef, un Salt-pillar, una Ansible-vault o una HashiCorp Vault. En nuestro ejemplo de Terraform, se almacena en un GCS bucket.

Descifrado

export GOOGLE_PROJECT=$(gcloud config get-value project)
export ENV=dev

gcloud kms decrypt --location=global --keyring=dev_keyring \
       --key=sa --plaintext-file=/dev/stdout \
       --ciphertext-file=<(gsutil cat gs://${GOOGLE_PROJECT}-secrets-${ENV}/elasticsearch_svc_account.json.enc)

En nuestro ejemplo de Terraform, podemos usar el proveedor de datos externos de Terraform como en este ejemplo para descargar y descifrar elásticosearch_svc_account.json.enc en la consola. El administrador de la nube puede proporcionar el servicio JSON al desarrollador que lo necesite a través de un canal seguro.

miércoles, 20 de diciembre de 2017

Cloud Shell es tu herramienta base

Hoy en google cloud español Publicado en 2017 dic 20 por Bastien Cadiot

Cloud Shell le ayuda a obtener acceso a sus instancias de Google Compute Engine

Hay muchas formas de acceder de forma remota a instancias en Google Compute Engine. Tradicionalmente utilizamos una VPN, una Interconexión o una instancia dedicada como punto central de control y gestión de acceso.

Google Cloud Platform ofrece otro método útil gracias a gcloud.
Puede instalar gcloud en su máquina, pero también puede usar gcloud incrustado en Cloud Shell (dentro de la consola de la nube).

Como un bastión perfecto, Cloud Shell viene con muchas herramientas preinstaladas y un almacenamiento persistente.

Intentemos conectarnos a una instancia con una IP externa:

$ gcloud compute ssh instance-1 --zone europe-west1-d

Pero si la instancia no tiene una dirección IP pública? Puede agregar uno temporalmente antes de intentar conectarse:

$ gcloud compute instances add-access-config instance-2 \
         --zone europe-west1-d
$ gcloud compute ssh instance-2 \
         --zone europe-west1-d
$ gcloud compute instances delete-access-config instance-2 \
         --zone europe-west1-d

Más información

Más detalles en la documentación dedicada: Conexión segura a instancias de VM

Usando Xen Citrix en Google Cloud

Hoy en google cloud español hablamos de los muchos clientes de Citrix y de sus clientes que utilizan soluciones de Google y Citrix como Receiver para Chrome, Android en la empresa con XenMobile y G Suite con ShareFile se preguntaron qué pasa con Google Cloud y la posible integración. Por lo que  principios de este año, Citrix y Google se unieron en  una colaboración más amplia para admitir Google Cloud para Citrix Cloud y el servicio XenApp y XenDesktop.

Explicaremos por encima la arquitectura técnica de cómo Citrix Cloud y XenApp se integran con Google Cloud Platform (GCP). Comencemos con una breve descripción general de Citrix Cloud con GCP. Citrix Cloud es un servicio de plataforma de administración e integración basado en la nube que simplifica la administración de la infraestructura de Citrix necesaria para entregar XenApp y XenDesktop.

En un modelo de Citrix Cloud, Citrix administra los componentes clave, como un controlador de Entrega, StoreFront, SQL y el servidor de Licencia. Esta arquitectura simplifica la gestión diaria y reduce los requisitos de IaaS en GCP para Citrix. Los componentes clave necesarios para conectar Citrix Cloud a GCP son simplemente los conectores en la nube, que son un conjunto de VMS que proporciona conectividad SSL sin alta disponibilidad (HA). a Citrix Cloud.

Por supuesto, también se requiere Active Directory, y con ese requisito, en su lugar, Cloud Connectors lo habilitará como una ubicación de recursos en Citrix Cloud. El Ejemplo 1 es un diagrama de referencia de cómo Citrix Cloud y GCP pueden entregar cargas de trabajo de XenApp utilizando el servicio NetScaler Gateway, que proporciona acceso remoto seguro para aplicaciones en GCP.



En la actualidad, las ubicaciones de nube de GCP tienen más de trece regiones, 39 zonas y más de 100 POP (punto de presencia). Cada región tiene un mínimo de dos zonas, lo que es crítico para la implementación de alta disponibilidad de las cargas de trabajo de IaaS y Citrix.

 

Google Compute Engine (GCE) para IaaS proporciona varias características únicas, como contenedores, arranque rápido de VM y tipos de máquinas personalizadas. El tipo de máquina personalizada GCE le permite al arquitecto encontrar el punto ideal para definir las cantidades exactas de ram y vCPU requeridas. A menudo, un VMS predefinido puede no ser suficiente para las aplicaciones, y los tipos de máquinas personalizadas resuelven ese desafío.

 
Tipo de máquina básica


 
Tipo de máquina personalizada

Cada región de GCP tiene plataformas de CPU Intel específicas disponibles y dada la amplia gama de opciones de procesadores como Sandy Bridge, Broadwell y Skylake, la necesidad de establecer un tipo específico puede ser de interés. La selección del tipo de CPU se puede realizar creando una plantilla y especificando el tipo mínimo de CPU con Google SDK o desde la interfaz de usuario en el menú de la plataforma de la CPU.




Demasiada información? pero estoy seguro de que se preguntan cómo comenzar a implementar XenApp en GCP. ¿Cómo escala XenApp en Google Cloud Platform? ¿Cuáles son los costos involucrados en las instancias de Windows dentro de GCP? ¿Y hay una guía paso a paso que me ayude a configurar Citrix Cloud y Google Cloud? Bueno, estás de suerte! 

La guía de implementación de Citrix Cloud y Google Cloud le ayudará a responder algunas de esas preguntas y más, mientras lo guía paso a paso para ayudarlo a implementar Citrix en Google Cloud. Esperamos escuchar sus comentarios, así que no dude en decirnos lo que piensa.

martes, 19 de diciembre de 2017

Primer deploy de aplicaciones con NPM en GAE

Hoy en google cloud español y de parte de Javier López

Cuando se desarrollan aplicaciones frontend con javascript que posteriormente se van a desplegar en GAE, es muy recomendable utilizar herramientas como NPM. 

Este gestor no solo nos va a ayudar con los paquetes de javascript, sino que se va a encargar de hacernos la vida más fácil con el deploy de la aplicación. Si es la primera vez que se utiliza NPM, cuando intentemos ejecutar el deploy ya sea en local (npm run devserver) o en GAE (npm run deploy) nos devolverá un error porque no está definida la variable "GCLOUD_SDK". 

Para que esto no suceda, debemos especificarle previamente el path donde se encuentra el SDK de Google Cloud. No obstante, a menudo tenemos en nuestro equipo varias descargas del SDK en diferentes directorios (como también suele pasa con Java) y no sabemos a ciencia cierta cual es la que el sistema está utilizando cuando llamamos al comando "gcloud".

Para no equivocarnos, existe un comando muy sencillo que nos devuelve siempre el path correcto: 

gcloud info --format="value(installation.sdk_root)"
Una vez obtenido el directorio, solo nos quedará por añadirle "/bin" al final y hacer el export del mismo y ya podremos ejecutar el deploy:

export GCLOUD_SDK=/home/ususario/ejemplo/google-cloud-sdk/bin
npn run deploy

Usando Firewall para el acceso a App Engine

Hoy en google cloud español publicado en 2017 dic 19 por Guillaume Laforge.

Permitir o no permitir el acceso a su aplicación a determinadas direcciones IP

Durante el verano, se presentó una nueva función beta para App Engine: el firewall de App Engine, una forma fácil de controlar el acceso a su aplicación. La función de firewall también se volvió disponible en general hace aproximadamente un mes.

El firewall le permite definir un conjunto de reglas, ordenadas por prioridad, que especifican una dirección IP o un conjunto de direcciones IP, para bloquear o permitir.

Para definir esas reglas, 3 enfoques están disponibles:

  • A través de la consola de Google Cloud,
  • Con solicitudes de REST a la API de administración de App Engine,
  • O a través de la CLI de gcloud.


Ejemplo

Al usar la CLI de gcloud, aquí está el patrón del comando para definir una nueva regla:

gcloud app firewall-rules create PRIORITY \
    --action ALLOW_OR_DENY \
    --source-range IP_RANGE \
    --description DESCRIPTION
Entonces, por ejemplo, si quiere bloquear el acceso a alguna red de direcciones maliciosa, podría hacer:

gcloud app firewall-rules create 100 \
    --action=deny \
    --source-range=203.0.113.0/24 \
    --description="Prevent access from rogue network"

Bonus

Una vez que haya actualizado sus reglas de firewall, también puede probar si una dirección IP en particular es aceptada o rechazada. Puede hacerlo desde la interfaz de usuario de la consola, así como con la CLI de gcloud:

gcloud app firewall-rules test-ip 203.0.113.2
Y hay comandos adicionales como lista para listar toda la configuración, o eliminar para eliminar algunas reglas por prioridad.

Más información

Puede obtener más información sobre el firewall de App Engine al leer la documentación: "Controlar el acceso con el cortafuegos".

lunes, 18 de diciembre de 2017

Triggering en Cloud Functions en carpetas de Cloud Storage

Publicado el 2017 Dec 18 por Graham Polley

Cloud Functions son una forma extremadamente poderosa y potente para resolver problemas. No necesitas funcionar con infraestructura ni intentar escalar. ¡Es de lo bueno lo mejor!

Sin embargo, al implementar su "cloud Function" para activar Google Cloud Storage, actualmente solo puede configurar el parámetro --trigger-bucket para que sea un bucket de GCS real.


Pero, ¿qué sucede si solo desea activar un archivo o carpeta en una carpeta específica dentro de ese cubo?


¡Sin problemas! Hay un pequeño truco para esto. De hecho, el nombre del objeto / archivo (es decir, el nuevo archivo que se ha cargado en su carpeta) en realidad contiene la ruta completa, incluidos los nombres de las carpetas. Entonces, en su Cloud Function todo lo que necesita hacer es verificar si la ruta incluye su nombre de carpeta:



function(event, callback) {
    const file = event.data;
    if (file.resourceState === 'exists' && file.name && 
        file.name.indexOf('my_lovely_folder/') !== -1) {
        //do stuff
        ...

Añada un dominio personalizado en App Engine


Al crear una aplicación de App Engine, es posible que desee utilizar un nombre de dominio personalizado, en lugar del generado en:  https: // [YOUR_PROJECT_ID] .appspot.com

Aquí es cómo:
  1. Compre su nombre de dominio en su registro favorito (por ejemplo, domains.google o namesilo.com).
  2. Dirígete a https://console.cloud.google.com/appengine/settings/domains/add?project=[YOUR_PROJECT_ID].
  3. Actualice los registros DNS de su dominio personalizado como se describe en el formulario.
  4. De forma predeterminada, obtendrá un certificado SSL gratuito, administrado por Google y con renovación automática.
  5. Disfrutalo.

Como buscar soluciones y tutoriales fácilmente

Busque a través de la documentación en línea y el los  tutorial

 Built-in search engine over the documentation, tutorials and codelabs
Motor de búsqueda incorporado sobre la documentación, tutoriales y codelabs

La documentación de GCP contiene toneladas de contenido excelente. Y si está trabajando con un servicio en particular, como Compute Engine, es bastante claro dónde debe buscar información.

Pero si desea encontrar soluciones y tutoriales, o resúmenes que abarquen la plataforma, no es tan obvio a dónde ir. Y la experiencia de búsqueda en el sitio no es de mucha ayuda, aquí.

Aquí está el consejo:

Use la página Cómo usar Google Cloud Platform para buscar documentos que podría estar perdiendo. GCP agrega nuevos tutoriales y soluciones todo el tiempo, así que marque esta página y úselo con frecuencia.

  • Puede escribir cualquier palabra clave o frase en el cuadro de búsqueda y la página filtrará los resultados.
  • Alternativamente, puede hacer clic en uno de los enlaces del navegador derecho para ver los filtros de categoría precocidos.
  • Puede proporcionar un enlace a los resultados de búsqueda simplemente agregando un hashtag al final de la URL: https://cloud.google.com/docs/tutorials#java

Como descargar y restaurar disco entre proyectos


En ocasiones, se necesita migrar un sistema en particular de un proyecto de cloud  a otro. Por ejemplo, migrar una configuración de Kafka o un repositorio de Nexus a un proyecto diferente, independientemente de si usa un disco local o persistente.

¿Cómo puedes lograr eso?. Volcando un disco y restaurándolo en otro proyecto. Y al usar imágenes personalizadas. Veamos cómo.

Requisito previo

En primer lugar, deberá instalar y configurar gcloud CLI SDK.

Creando una imagen personalizada

Primero, volquemos el disco local como una imagen personalizada:


gcloud compute images create data_dump \
    --project=<project_a> \
    --source-disk=source-disk-name \
    --source-disk-zone us-central1-b \
    --force


Nota: --force puede usarse para un disco conectado a una instancia en ejecución, tenga en cuenta esto, ya que no se recomienda crear una imagen personalizada desde un disco en uso activo.

Enumera las imágenes personalizadas de project_a


gcloud compute images list \
    --no-standard-images \
    --project=<project_a>

Crear disco en el nuevo proyecto project_b

gcloud compute disks create data_disk \
    --image=projects/<project_a>/global/images/data_dump \
    --project=<project_b>

¡Ahora está listo para realizar una instantánea de data_disk o adjuntar data_disk a cualquier instancia en ejecución en project_b!