lunes, 16 de septiembre de 2019

El Martes hablamos sobre: "Ayudas de Google Cloud para Profesores y estudiantes2 [Evento On-Line]


Este Martes a las 19:00 hora [hora de España]  realizamos un evento On-line para hablaros de los recursos de Google pone a disposición de los educadores y para la educación.

De la mano de Marcos Manuel https://www.linkedin.com/in/marcosmanuelortega/?originalSubdomain=es nos hablara de las opciones y recursos dentro de Google Cloud.

El enlace del evento On line es:

https://www.youtube.com/watch?v=KsFn8Kly1FI

Con el inicio del curso os hablamos de que recursos presenta Google para poder pedir crédito para profesores y alumnos.


UPDATE------
Aquí las URL de interés de las que hablamos en el canal

https://www.youtube.com/watch?v=KsFn8Kly1FI http://bit.ly/CloudEspañolAyudasGCP https://edu.google.com/programs

lunes, 2 de septiembre de 2019

Usando Sigfox con Google Cloud IOT ejemplo de Solucion.[Markku Lepisto]


Después de su charla en el Google IO con un ejemplo en directo, esta vez y de la mano de Sigfox demuestra en un evento on-line la como funciona la plataforma Sigfox con Google Cloud.

Markku Lepisto, (Arquitecto de soluciones - APAC y Japón, Google Cloud Platform)
Presento:

  • -¿Cuál es la integración Sigfox-GCP y su valor?
  • -Demostración en vivo de la configuración de integración usando Sigfox Backend y Google Cloud
  • -Ejemplo de dispositivo de finalización con Sigfox Sens'it 
  • -live Sens'it en la demostración de GCP que incluye análisis binario de carga útil, análisis en tiempo real y gestión de configuración de dispositivos -diseño de ejemplo de seguimiento de activos con Pycom / Pytrack GPS, Sigfox Atlas Geolocation, Google BigQuery -GIS y mapas
  • -Demostración de seguimiento de activos en directo.

Consulta a continuación los videos y tutoriales de integración de Sigfox y GCP:

miércoles, 21 de agosto de 2019

IOT la red de Sigfox y Google Cloud por fin en marcha.



¡Sigfox une fuerzas con el equipo del Programa Google Cloud for Startups para que sus miembros del Programa STARTER se beneficien del paquete Google Spark!

Si cumple con los requisitos de GCP * y ya está registrado en el Programa STARTER, recibirá $ 20,000 en Google Cloud Platform y Firebase Credits, válidos por 12 meses.

Más información sobre la activación de beneficios aquí.


¿Cómo empezar a usarlo?

¡Unase  a la próxima conferencia en línea de Sigfox Explore para descubrir cómo usar Sigfox con GCP!

Conocerá a Markku Lepisto, (Arquitecto de soluciones - APAC y Japón, Google Cloud Platform) que le dará una demostración en directo (on-line) de un caso de uso de seguimiento de activos utilizando:
Pycom + Atlas Geoloc + GCP + Maps.

Agenda:

  • ¿Cuál es la integración de Sigfox GCP y su valor?
  • Demostración en vivo de la configuración de integración con Sigfox Backend y Google Cloud
  • Ejemplo de dispositivo de extremo a extremo con Sigfox Sens'it
  • Demostración de Live Sens'it en GCP que incluye análisis de carga útil binaria, análisis en tiempo real y administración de la configuración del dispositivo
  • Diseño de ejemplo de seguimiento de activos con Pycom / Pytrack GPS, Sigfox Atlas Geolocation, Google BigQuery-GIS y Maps
  • Demostración de seguimiento de activos en vivo.
Link para unirse a la conferencia aqui.

miércoles, 14 de agosto de 2019

Cloud Run VS Cloud Functions: ¿Cuál es el más barato?

Autor: https://twitter.com/gblaquiere
Enlace original 




Elegir una solución desde un punto de vista técnico es importante, pero el coste de un servicio no debe olvidarse porque, en un entorno de escala automática, puede explotar sin previo aviso.
La comparación se realizó sólo en función de los precios y las cuotas y límites de cada producto. El rendimiento del procesamiento se supone igual en ambos

Cloud functions


El precio de las funciones en la nube se basa en la vCPU en GHz / sy la memoria en Gb / s, redondeada a los 100 ms más cercanos. La especificidad de las funciones es que puede ajustar la memoria y la velocidad de la CPU, pero no por separado. Ambos están vinculados, aumente la memoria si desea más MHz y viceversa.


El precio de salida de la red es una tarifa plana de $ 0,12 / Gb
Finalmente, las solicitudes se facturan a $ 0,40 el millón de solicitudes después de los primeros 2 millones de cuota gratuita.

Cloud Run (administrado)


El precio de Cloud Run se basa en vCPU / sy la memoria en Gb / s, redondeada a los 100 ms más cercanos. No es posible usar vCPU parcial por instancia. Su instancia siempre tiene 1 vCPU asignada. La memoria se puede ajustar de 128Mb a 2Gb

Una instancia puede manejar hasta 80 solicitudes concurrentes. Por lo tanto, para una instancia determinada, solo se le cobra cuando la instancia procesa al menos una solicitud.




La salida de la red se basa en el precio del Nivel Premium de la red después de 1 Gb de nivel gratuito.
Finalmente, las solicitudes se facturan a $ 0.40 cada millón de solicitudes después de los primeros 2 millones de solicitudes de cuota gratuita


En resumen


El costo de la red es ligeramente diferente con 5 Gb de nivel libre de salida para Cloud Functions y solo 1 para Cloud Run -> alrededor de $ 0.50 de diferencia. Pero el precio de salida de GB no es el mismo, y es más complejo en Cloud Run, basado en el Nivel Premium de red. En Europa y América del Norte, es notablemente más barato con Cloud Run comparado con Asia.

Las Cloud Functions permiten ajustar la velocidad de vCPU de acuerdo con la memoria utilizada. Pero solo puede manejar 1 solicitud por instancia.

Cloud Run siempre usa 1 vCPU; solo puedes ajustar la memoria. Pero Cloud Run puede procesar solicitudes concurrentes en la misma instancia.

Finalmente, el coste de la cantidad de solicitudes es estrictamente el mismo.

Por cierto, podemos considerar 2 casos principales de comparación: con solo 1 solicitud concurrente y con varias solicitudes simultáneas.

Para este caso se crea una GSheet para jugar con memoria, concurrencia y valores de requisitos de proceso.

Un caso de solicitud concurrente


En este caso, solo se compara el procesamiento de 1 solicitud. En este caso, Cloud Run y ​​Cloud Functions tienen exactamente 1 instancia para procesar esta solicitud única y, por lo tanto, solo se cobra esta instancia.

Este caso puede ocurrir si configura para una sola concurrencia en Cloud Run, o si tiene solicitudes dispersas y secuenciales a su servicio

Por lo tanto, en la misma condición, con 1 vCPU (2.4Ghz) y 2Gb de memoria, el precio y el rendimiento son estrictamente los mismos entre Cloud Run y ​​Cloud Functions.


Caso de varias solicitudes concurrentes

La mayoría de las veces, un servicio maneja varias solicitudes al mismo tiempo. Cloud Run tiene la capacidad de manejar hasta 80 solicitudes concurrentes con la misma instancia.

Por el contrario, Cloud Functions crea tantas instancias como las solicitudes concurrentes.
De este modo, más puede procesar la solicitud simultáneamente con Cloud Run, más barato es el servicio.




Que podemos valorar


La mejor opción depende de lo que desee optimizar, sus casos de uso y sus necesidades específicas.

Latencia más baja


Si su objetivo es la latencia más baja, elija Cloud Run.
De hecho, Cloud Run usa siempre 1 vCPU (al menos 2.4Ghz) y puede elegir el tamaño de memoria de 128Mb a 2Gb.

Con Cloud Functions, si se necesita el mejor rendimiento de procesamiento (2,4 Ghz de CPU), debe pagar 2 Gb de memoria. Si su necesidad de memoria es baja, las cloud function con 2 Gb de memoria son excesivas y cuestan nada.

Menor costo


Reducir los costos no siempre es la mejor estrategia para la satisfacción del cliente, pero la realidad empresarial puede requerirlo. De todos modos, depende mucho de su caso de uso.

Tanto Cloud Run como Cloud Function se redondean a los 100 ms más cercanos. Como podría jugar con la GSheet, las funciones en la nube son más baratas cuando el tiempo de procesamiento de 1 solicitud es inferior a los primeros 100 ms.

De hecho, puede ralentizar la vCPU de Cloud Functions, lo que tiene como consecuencia aumentar la duración del procesamiento, pero mientras se mantiene por debajo de 100 ms si lo ajusta bien. Por lo tanto, se utilizan menos Ghz / s y, por lo tanto, paga menos.

Por ejemplo, con un bajo requerimiento de procesamiento (se requieren 20Mhz) que requirió solo 128Mb de memoria, tiene:


  • Cloud Functions: 100 ms de procesamiento por un costo de $ 0.23e-6
  • Cloud Run: 8 ms de procesamiento por un costo de $ 2.4e-6





Claro, Cloud Functions es 10 veces más barato, pero sus clientes esperan 10 veces más. Y esta comparación de precios es cierta SOLO si tiene solicitudes secuenciales.

En este ejemplo, con más de 10 solicitudes simultáneas, ¡Cloud Run es más barato! De hecho, Cloud Run maneja hasta 80 solicitudes concurrentes en la misma instancia antes de crear (y facturar) una nueva.


Por el contrario, Cloud Functions maneja las solicitudes concurrentes en diferentes instancias y, por lo tanto, debe pagar cada instancia en ejecución además del sobrecoste de arranque en frío para cada
instancia creada.

Hay otro caso en el que las Cloud Functions son más baratas y es una buena idea ralentizar la vCPU: cuando una aplicación llama a las API y espera las respuestas. Tener una función con 200Mhz es suficiente y una vCPU completa de Cloud Run es exagerada (para ninguno o pocos procesos) y, por lo tanto, es costosa.

Limitación de instancia


En la página de Limitación y Cuota de cada producto, el número de instancias paralelas está limitado a 1000.

Sin embargo, con las Cloud Functions, es posible establecer un límite superior personalizado para limitar el número de instancias paralelas. Inicialmente lanzado para limitar el uso de recursos (por ejemplo, conexión de base de datos), también es una gran funcionalidad para limitar los gastos y establecer el límite superior del costo de su servicio. Pero siempre con un impacto negativo en la satisfacción del usuario en caso de saturación.

Cloud run aún no ofrece este tipo de limitación personalizable

Manejo de eventos


Las funciones en la nube se pueden activar mediante solicitudes HTTP (llamadas funciones HTTP) pero también por eventos activados en el entorno Google Cloud (llamadas funciones en segundo plano)

Por el contrario, los contenedores de Cloud Run solo pueden ser llamados por solicitudes HTTP. Sin embargo, es posible usar la suscripción de inserción de PubSub para impulsar los eventos de PubSub para que Cloud Run los procese. Además, también es posible publicar eventos de almacenamiento en el tema de PubSub y, por lo tanto, procesar eventos de almacenamiento con Cloud Run nuevamente a través de una suscripción push de PubSub. Pero no más.

Por lo tanto, a excepción de los eventos PubSub y Storage, las Cloud Functions son inevitables para todos los demás tipos de eventos. No hay elección posible.

Requisito de conexión VPC


Su aplicación sin servidor puede requerir algunos recursos privados solo disponibles en su VPC. Por ejemplo, un almacén de memoria para almacenamiento de clave-valor de baja latencia, o un acceso VPN / conexión directa para alcanzar recursos externos (OnPremise o en otra nube).

Las cloud Function permiten configurar un conector VPC para conectar sus funciones sin servidor a su VPC, y así enrutar el tráfico según sea necesario.
Hasta ahora, no era posible con Cloud Run administrado, pero podría cambiar a fines de 2019.

Que elegir

Antes de mi conclusión, me gustaría agregar algunas consideraciones adicionales, no directamente vinculadas al precio de la plataforma, sino también en todo el proceso de desarrollo, servicio y monitoreo.

A tener en cuenta sobre el costo

Las nubes públicas vienen con una nueva capacidad: el verdadero conocimiento del coste. En mi empresa, el coste de la nube generó miedos: ¡Woah, es caro! No, no lo es, pero es conocido, visible.

En un entorno local, es muy difícil saber el costo real por servicio, especialmente el costo humano o los recursos mutualizados (red, almacenamiento, alojamiento, ...).

Cuando elige una solución técnica, es importante tener en cuenta todas las piezas del proyecto y, en primer lugar, sus recursos humanos. Las funciones en el cloud parecen más baratas porque su caso de uso les queda bien. Pero, ¿su equipo puede desarrollar funciones en los idiomas disponibles?

En mi empresa, nuestra pila heredada (y experiencia) era PHP y C ++ y esto no se ajustaba a la capacidad de Cloud Functions. Por eso, los Docker fueron nuestra elección, incluso antes de que existiera el producto Cloud Run.

¿Realmente sabes el coste de tu equipo?

  • Riesgo de renuncia porque las personas no están bien con una nueva pila
  • Coste de la sesión de aprendizaje además de la ausencia de productividad durante el tiempo de aprendizaje.
  • La falta de calidad de código, fiabilidad, rendimiento y productividad debido a la nueva implementación de código.
Todas estas razones son, la mayoría de las veces, mucho más caras que el costo del proveedor de la nube.

Además de este aspecto humano, ¿cuál será el costo de la refactorización en caso de portabilidad? ¿Cuál será el costo de X% más de errores debido a las dificultades de las pruebas o la falta de experiencia en un nuevo idioma?

Aplicación crítica

Hoy, Cloud Run está en beta. En Google Cloud Platform, las versiones beta son realmente estables y se pueden usar en producción. Sin embargo, no existe un compromiso de Google con el servicio y el soporte puede ser menos eficiente.

Las funciones en la nube están en GA para Python 3, Node 8 y Go 1.11

En la aplicación de misión crítica con SLA restrictivo, esta puede ser la primera opción de criterio, por encima del costo mismo.

Límites y cuotas

Existen pocas diferencias entre los 2 servicios, pero pueden implicar un cambio organizacional o un rediseño de diseño de solución técnica. Este es un costo indirecto, pero a tener en cuenta si planea implementar cientos de funciones en el cloud con una alta velocidad de implementación.

De hecho, las cloud Function están limitadas a 1000 funciones por proyecto y a 120 minutos de compilación por día y por proyecto.

En Cloud Run, no hay límite en la compilación porque se realiza fuera de la plataforma, y ​​existe el mismo límite de 1000 servicios por proyecto. PERO un servicio puede servir a varios endpointss.

Otro aspecto es el tamaño de cada solicitud / respuesta 3 veces mayor con Cloud Run que con Cloud Functions. ¿Su caso de uso se ve afectado por esto?
Otros límites son difíciles de comparar o no son relevantes para una gran mayoría de proyectos.


Conclusión

Como se puede ver, la comparación de costos entre Cloud Functions y Cloud Run va más allá de simplemente comparar una lista de precios. Además, en sus proyectos, a menudo tendrá que usar las 2 soluciones para aprovechar sus fortalezas y capacidades.

La primera opción para el desarrollo es Cloud Run. Su portabilidad, su capacidad de prueba, su apertura en las bibliotecas, los idiomas y los archivos binarios le confieren demasiadas ventajas para, al menos, un precio similar, y a menudo con una ventaja real en el costo pero también en el rendimiento, en particular para solicitudes concurrentes. Incluso si necesita el mismo nivel de aislamiento de las funciones de la nube (1 instancia por solicitud), ¡simplemente configure el parámetro de concurrencia en 1!

Sin embargo, algunas razones, como el soporte de GA, la capacidad de VPC o los eventos, pueden obligarlo a elegir Cloud Functions, pero, la mayoría de las veces, no será por una razón de precios.

Finalmente, la variedad de casos de uso, las diferencias en la organización y la complejidad de los recursos humanos (habilidades, deseos, motivaciones) generan demasiadas combinaciones y solo puedo proporcionar consejos y cosas que no olvidar en su proceso de decisión. No es posible proporcionar una respuesta única.

En cualquier caso, asegúrese de elegir el socio adecuado, con un punto de vista externo, que lo ayude en este viaje, hable con sus equipos y trate de encontrar la mejor respuesta a sus casos de uso.

jueves, 1 de agosto de 2019

Cómo programar un script de Python en GCP


Tal vez estés ejecutando una consulta en BigQuery y descargando los resultados en BigTable cada mañana para realizar un análisis. O quizás necesite actualizar los datos en una tabla dinámica en Google Sheets para crear un histograma  para mostrar sus datos de facturación. En cualquier caso, a nadie le gusta hacer lo mismo todos los días si la tecnología puede hacerlo por ti. ¡Contempla la magia de Cloud Scheduler, Cloud Functions y PubSub!

Cloud Scheduler es un producto administrado de Google Cloud Platform (GCP) que te permite especificar una frecuencia para programar un trabajo recurrente. En pocas palabras, es un planificador de tareas gestionado ligero. Esta tarea puede ser un trabajo por lotes ad hoc, un trabajo de procesamiento de big data, herramientas de automatización de infraestructura, lo que sea. Lo bueno es que Cloud Scheduler se encarga de todo el trabajo ademas  se reintenta en caso de fallo e incluso le permite ejecutar algo a las 4 AM, para que no tenga que despertarse en medio de la noche para correr una carga de trabajo en otro momento fuera de hora punta.


Al configurar el trabajo, puedes determinar qué exactamente "disparará" en un momento concreto Puede tratarse de un publicación en un  PubSub,  o un end-point de  HTTP o una aplicación App Engine. En este ejemplo, publicaremos un mensaje a un tema de PubSub.

Nuestro tema de PubSub existe únicamente para conectar los dos extremos de nuestra canalización: es un mecanismo intermediario para conectar el trabajo de Cloud Scheduler y la función en cloud que contiene la secuencia de comandos de Python real que ejecutaremos. Esencialmente, el tema de PubSub actúa como una línea telefónica, proporcionando la conexión que permite que el trabajo del Programador del cloud  hable y la Función de la Nube para escuche. Esto se debe a que el trabajo de Cloud Scheduler publica un mensaje al tema. La función de nube se suscribe a este tema. Esto significa que se alerta cuando se publica un nuevo mensaje. Cuando recibe una alerta, ejecuta el script de Python.

The Code

SQL

Para este ejemplo,  mostraré un script de Python simple que quiero ejecutar diariamente a las 8 AM  y las 8 PM . El script es básico: ejecuta una consulta SQL en BigQuery para encontrar los repositorios populares de Github. Buscaremos específicamente qué propietarios crearon repositorios con la mayor cantidad de contenedores y en qué año se crearon. Usaremos datos del conjunto de datos público bigquery-public-data: sample, que contiene datos sobre los repositorios creados entre 2007 y 2012.

Nuestra consulta SQL tiene este aspecto:

SELECT
  SUM(repository.forks) AS sum_forks,
  repository.owner,
  EXTRACT(YEAR FROM PARSE_TIMESTAMP('%Y/%m/%d %H:%M:%S %z', repository.created_at)) AS year_created
FROM
  `bigquery-public-data.samples.github_nested`
WHERE
  repository.created_at IS NOT NULL
GROUP BY
  2,
  3
ORDER BY
  3 DESC

Python

Pronto pegaremos esta consulta en nuestro archivo github_query.sql. Esto se llamará en nuestro archivo main.py, que llama a una función principal que ejecuta la consulta en Python mediante el uso de Python Client Library para BigQuery.

Paso 1: asegúrese de tener Python 3 e instale e inicialice el SDK de google cloud. Lo siguiente les una guia a través de cómo crear el entorno GCP. Si desea probarlo localmente, asegúrese de haber seguido primero las instrucciones para configurar Python 3 en GCP.

Paso 2: crea un archivo llamado requirements.txt y copia y pega lo siguiente:

  google-cloud-bigquery
Paso 3: Crea un archivo llamado github_query.sql y pega en la consulta SQL desde arriba.

Paso 4: Cree un archivo llamado config.py y edítelo con sus valores para las siguientes variables.

Puede usar un conjunto de datos existente para esto o elegir un ID de un nuevo conjunto de datos que creará, solo recuerde el ID ya que lo necesitará para otorgar permisos más adelante.

  config_vars = {
    'project_id': [ENTER YOUR PROJECT ID HERE],
    'output_dataset_id': '[ENTER OUTPUT DATASET HERE]',
    'output_table_name': '[ENTER OUTPUT TABLE NAME HERE]',
    'sql_file_path': 'github_query.sql'
}
Paso 4: Cree un archivo llamado main.py que haga referencia a los dos archivos anteriores.

"""Function called by PubSub trigger to execute cron job tasks."""
import datetime
import logging
from string import Template
import config
from google.cloud import bigquery

def file_to_string(sql_path):
    """Converts a SQL file holding a SQL query to a string.
    Args:
        sql_path: String containing a file path
    Returns:
        String representation of a file's contents
    """
    with open(sql_path, 'r') as sql_file:
        return sql_file.read()


def execute_query(bq_client):
    """Executes transformation query to a new destination table.
    Args:
        bq_client: Object representing a reference to a BigQuery Client
    """
    dataset_ref = bq_client.get_dataset(bigquery.DatasetReference(
        project=config.config_vars['project_id'],
        dataset_id=config.config_vars['output_dataset_id']))
    table_ref = dataset_ref.table(config.config_vars['output_table_name'])
    job_config = bigquery.QueryJobConfig()
    job_config.destination = table_ref
    job_config.write_disposition = bigquery.WriteDisposition().WRITE_TRUNCATE
    sql = file_to_string(config.config_vars['sql_file_path'])
    logging.info('Attempting query on all dates...')
    # Execute Query
    query_job = bq_client.query(
        sql,
        job_config=job_config)

    query_job.result()  # Waits for the query to finish
    logging.info('Query complete. The table is updated.')

def main(data, context):
    """Triggered from a message on a Cloud Pub/Sub topic.
    Args:
        data (dict): Event payload.
        context (google.cloud.functions.Context): Metadata for the event.
    """
    bq_client = bigquery.Client()

    try:
        current_time = datetime.datetime.utcnow()
        log_message = Template('Cloud Function was triggered on $time')
        logging.info(log_message.safe_substitute(time=current_time))

        try:
            execute_query(bq_client)

        except Exception as error:
            log_message = Template('Query failed due to '
                                   '$message.')
            logging.error(log_message.safe_substitute(message=error))

    except Exception as error:
        log_message = Template('$error').substitute(error=error)
        logging.error(log_message)

if __name__ == '__main__':
    main('data', 'context')
Para implementar la función en GCP, puede ejecutar los siguientes comandos de gcloud. Esto especifica el uso de un tiempo de ejecución de Python 3.7,
La creación de un tema de PubSub con un nombre de su elección y la especificación de que esta función se activa cada vez que se publica un nuevo mensaje sobre este tema. También esta establecido el tiempo de espera al máximo que GCP ofrece de 540 segundos o nueve minutos.

gcloud functions deploy [FUNCTION_NAME] --entry-point main --runtime python37 --trigger-resource [TOPIC_NAME] --trigger-event google.pubsub.topic.publish --timeout 540s
Asegúrese de que primero cd en el directorio donde se encuentran los archivos antes de la implementación, de lo contrario no funcionará lo siguiente.

Especifica la frecuencia con la que se ejecutará la función de la nube en el tiempo cron de UNIX al configurar el programador del Cloud  con el indicador de programación. Esto significa que publicará un mensaje al tema de PubSub cada 12 horas en la zona horaria UTC, como se ve a continuación:

gcloud scheduler jobs create pubsub [JOB_NAME] --schedule [SCHEDULE] --topic [TOPIC_NAME] --message-body [MESSAGE_BODY]
donde [JOB_NAME] es un nombre único para un trabajo, [SCHEDULE] es la frecuencia para el trabajo en UNIX cron, como "0 * / 12 * * *" para ejecutar cada 12 horas, [TOPIC_NAME] es el nombre del tema creado en el paso anterior cuando implementó la función de nube, y [MESSAGE_BODY] es cualquier cadena. Un ejemplo de comando sería:


gcloud scheduler jobs create pubsub daily_job --schedule "0 */12 * * *" --topic my-pubsub-topic --message-body "This is a job that I run twice per day!"

Nuestro código de Python no usa el mensaje real. ¡Este es un trabajo que ejecuto dos veces por día! "" Publicado en el tema porque solo estamos ejecutando una consulta en BigQuery, pero vale la pena señalar que puede recuperar este mensaje y actuar. tal, como para fines de registro o de otro tipo.

Conceder permisos
Finalmente, abra la interfaz de usuario de BigQuery y haga clic en "Crear conjunto de datos" en el proyecto al que hizo referencia anteriormente.

Al crear la Función de la nube, creó una cuenta de servicio con el correo electrónico en el formato [PROJECT_ID] @ appspot.gserviceaccount.com. Copia este correo electrónico para el siguiente paso.

Pase el cursor sobre el ícono Más para este nuevo conjunto de datos.

Haga clic en "Compartir conjunto de datos".

En la ventana emergente, ingrese el correo electrónico de la cuenta de servicio. Dale permiso "Can Edit".

Ejecutar el trabajo:
Puede probar el flujo de trabajo anterior ejecutando el proyecto ahora, en lugar de esperar la hora programada de UNIX. Para hacer esto:


  1. Abre la página de Cloud Scheduler en la consola.
  2. Haz clic en el botón "Ejecutar ahora".
  3. Abre BigQuery en la consola.
  4. Debajo de su conjunto de datos de salida, busque su [output_table_name], esto contendrá los datos.


Para obtener más información, lea nuestra documentación sobre la configuración de Cloud Scheduler con PubSub trigger y pruébelo utilizando uno de nuestros conjuntos de datos públicos de BigQuery.

domingo, 28 de julio de 2019

Master en sintaxis de la configuración yaml en [Google Cloud Build]




La plataforma de automatización de Cloud Build de Google se basa en una serie de pasos de "constructores" en contenedores, especificados en un archivo de configuración YAML.

Para cada paso, GCB arranca un contenedor Docker y ejecuta un comando específico dentro del contexto de ese contenedor, como Gradle, gcloud o Wget. Puede pasar uno o más argumentos a ese comando usando el campo args en su archivo cloudbuild. yaml.

Esta sintaxis facilita la puesta en marcha de un proceso de compilación básico. Pero a medida que agrega complejidad a su proceso , puede encontrar que su YAML se vuelve difícil de analizar y mantener, o incluso que hay cosas que necesita hacer que simplemente no se pueden expresar. 

En esta publicación, mostraremos formas alternativas de escribir su configuración de creación en el Cloud de estos yaml. Al aplicar estas best practices, tendrá archivos de configuración más legibles y mantenibles. Aún mejor, puede aprovechar el poder oculto de Cloud Build para crear tus pipelines avanzadas con tus  CI / CD.


Como ejemplo, realizaremos un paso de compilación que recupera texto de una API remota y lo imprime en la consola. Empecemos con la versión más simple de la configuración:

Sintaxis simple


steps:
- name: 'gcr.io/cloud-builders/curl'
  args: ['https://pets.doingdevops.com/pet','-s','--max-time','10']

Esta es la sintaxis más común que se encuentra en la documentación, y suele ser el la forma correcta para comenzar.

Práctica recomendada: use esto para trabajos simples: es conciso y fácil de leer.

Sintaxis expandida (collection style)


También funciona si agregamos saltos de línea a la sintaxis simple:

steps:
- name: 'gcr.io/cloud-builders/curl'
  args:
    [
      'https://pets.doingdevops.com/pet',
      '-s',
      '--max-time', '10', # related args on one line
    ]

Al agregar saltos de línea, dejamos espacio para argumentos largos, y hacemos que sea más fácil ver dónde termina un argumento y comienza el siguiente. Esto es especialmente útil cuando se usan variables o estructuras de datos dentro de argumentos, que pueden ser difíciles de leer fácilmente.

Sin embargo, la regla de un argumento por línea no se aplica en realidad. Por lo tanto, si varios argumentos están relacionados, se pueden agrupar una línea. En este ejemplo, los argumentos --max-timeand 10 están en la misma línea, para hacer evidente que uno se refiere al otro.

Best practice: use esta sintaxis cuando la sintaxis básica se vuelva complicada: muchos argumentos, argumentos largos, complejidad dentro de los argumentos, etc. !Cuidado con la gestión de las comas finales¡

Sintaxis expandida (estilo de lista)

Alternativamente, podemos escribir el paso usando una lista YAML, con un argumento por línea, prefijado con guiones. Los argumentos pueden no estar citados, pero eso es una mala idea; es muy difícil leer un argumento como - -s: ¿ese guión-espacio-guión? o espacio-dash-dash? o…?
steps:
- name: 'gcr.io/cloud-builders/curl'
  args:
  - 'https://pets.doingdevops.com/pet'
  - '-s'
  - '--max-time'
  - '10'

Si bien esto es similar a la "sintaxis expandida (estilo de colección)", tiene algunas desventajas:

  1. Tener un guión por argumento reduce la legibilidad, especialmente porque muchos argumentos tendrán sus propios guiones;
  2. No puedes agrupar múltiples argumentos en una sola línea
  3. Es más difícil convertir desde la "sintaxis simple".

Mejores Prácticas: No usar. (Prefiere "estilo de colección".)


Breakout syntax

Cada constructor tiene un punto de entrada predeterminado, que generalmente se relaciona con el propósito de ese constructor. Por ejemplo, el punto de entrada del constructor Gradle es gradle. 

Cuando se invoca un paso de compilación de gradle, el comando de gradle se ejecuta en el contenedor, con todo en la matriz de argumentos que se pasa como argumentos a Gradle.

Pero no estamos limitados solo al comando predeterminado: podemos "romper" y ejecutar cualquier comando disponible en el contenedor, simplemente especificando un punto de entrada alternativo.

La mayoría de los constructores han instalado bash, lo que nos brinda la máxima flexibilidad para hacer todo lo que deseamos dentro de nuestro paso. Esta es la misma operación, pero invocando a bash directamente:
steps:
- name: 'gcr.io/cloud-builders/curl'
  entrypoint: 'bash'
  args:
  - '-c' # pass what follows as a command to bash
  - |
    curl -s 'https://pets.doingdevops.com/pet' --max-time 10

Aquí, se usa una sintaxis de bloque YAML (el argumento está precedido por "|"), por lo que podemos pasar una cadena multilínea sin comillas como el comando. ¿Y qué hemos logrado exactamente? ¡Nada! Esto sigue haciendo lo mismo que el ejemplo "simple". Pero ahora tenemos todo el poder para ejecutar comandos bash arbitrarios. Así que podemos hacer más. Mucho más…

Supongamos que la API remota es inestable; a veces falla En ese caso, queremos volver a intentarlo hasta que tenga éxito. Aquí hay un ejemplo que usa múltiples comandos y lógica condicional para asegurar que obtengamos una respuesta válida:
steps:
- name: 'gcr.io/cloud-builders/curl'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    PET="$$(curl -s https://pets.doingdevops.com/pet_flaky --max-time 10)"
    while [ "$$PET" == "ERROR" ] ; do
      echo "Error: API failed to respond with a pet! Try again..."
      PET="$$(curl -s https://pets.doingdevops.com/pet_flaky --max-time 10)"
  done
  echo "Success! $${PET}"

Tenga en cuenta el uso de signos de dólar dobles ($$) como caracteres de escape. Esto garantiza que Cloud Build los pasará al contenedor, en lugar de interpretarlos como sustituciones.

Al anular el punto de entrada y unir los comandos de bash, podemos hacer todo lo posible dentro de los límites de este contenedor . Y si necesita hacer algo que no esté disponible en un constructor existente, puede crear su propia imagen de constructor personalizada; asegúrese de incluir un shell (por ejemplo, bash) si planea usar la sintaxis de "breakout".

¿Qué es algo interesante que hayas hecho con Cloud Build? Deja una nota en los comentarios!

Los archivos de configuración de ejemplo, y la fuente de los servicios API remotos, se pueden encontrar en github.com/davidstanke/gcb-syntax-blog.

sábado, 20 de julio de 2019

Debug en producción usando los repositorios de Google Cloud

Google Cloud tiene herramientas geniales para desarrolladores de software. Los repositorios de Cloud Source y el debugger de  Stackdriver son utilizados diariamente por miles de desarrolladores que valoran la excelente búsqueda de códigos de Cloud Source Repositories y la capacidad del Debugger para encontrar errores de forma rápida y segura en los servicios de producción.

Pero Debugger no es un navegador de código completo, y no está estrechamente integrado con todos los entornos de desarrollador más comunes. ¡La buena noticia es que estas herramientas se están juntando! A partir de hoy, puede hacer debug sus servicios de producción directamente en los repositorios de origen del Cloud de Google , para cada servicio en el que esté habilitado el stackdriver Debugger activado.


Lo nuevo en los repositorios de Cloud Source

Esta integración aporta dos piezas de funcionalidad a los repositorios en el cloud: soporte para Snapshots  y logpoints.

Snapshots


Los snapshots son imágenes puntuales de las variables locales y del stack de su aplicación que se activan cuando se cumple una condición de código. Piense en los snapshots como puntos de interrupción que no detienen la ejecución.

Para crear uno, simplemente haga clic en un número de línea como lo haría con un debugger tradicional, y el snapshot se activará la próxima vez que una de sus instancias ejecute la línea seleccionada. Cuando esto suceda, verás las variables locales capturadas durante el snapshot y la pila de llamadas completa, ¡sin detener la aplicación ni afectar su estado y las operaciones en curso!

Puede navegar y ver las variables locales en esta instantánea desde cada stack, al igual que con cualquier otro debugger. También tiene acceso completo a las condiciones y expresiones, y existen medidas de seguridad para protegerse contra cambios accidentales en el estado de su aplicación.



Logpoints

Los puntos de registro  "logpoints" le permiten insertar dinámicamente las declaraciones de registro en sus servicios en ejecución sin volver a implementarlos. Cada punto de registro funciona como una declaración de registro que escribe normalmente en su código: puede agregar texto libre, variables de referencia y establecer las condiciones para que se guarde el registro. Los logpoints se escriben en su ruta de salida estándar, lo que significa que puede utilizarlos con cualquier backend de registro, no solo con el registro del controlador de pila.

Crear un punto de registro es muy parecido a crear un snapshots: simplemente haga clic en el número de línea de la línea en la que desea establecerlo y listo.

Al agregar un logpoint a su aplicación, se envía a todas las instancias del servicio seleccionado. Los puntos de registro duran 24 horas o hasta que el servicio se vuelve a implementar, lo que ocurra primero. Los logpoints tienen el mismo impacto en el rendimiento que cualquier otra declaración de registro que existe normalmente en su código fuente.


Por dónde empezar


Para usar las capacidades de debugger de producción de Cloud Source Repositories, primero debe habilitar en sus proyectos de Google Cloud Platform para el Debugger de Stackdriver. Puede obtener más información sobre estos pasos de configuración en la documentación del Depurador de Stackdriver.

Una vez que se haya completado, navegue hasta el código fuente que desea depurar en los repositorios de Cloud Source, luego seleccione ‘Depurar aplicación’. Hoy en día, esto funciona mejor con el código almacenado en los repositorios de origen del cloud o que se refleja en fuentes de terceros compatibles, como GitHub, Bitbucket y GitLab. Una vez que haya seleccionado su aplicación, puede comenzar a colocar snapshots y logpoints en su código haciendo clic en los números de línea en el margen izquierdo.






Debugger en la  producción.

Ser capaz de depurar el código que se está ejecutando en producción es una capacidad crítica, y poder hacerlo desde un navegador de código con todas las funciones es aún mejor. 

Ahora, al llevar la depuración de producción a los repositorios de origen del cloud, puedes rastrear problemas difíciles de encontrar en el fondo de su código, mientras puede hacer cosas como sincronizar continuamente el código de una variedad de fuentes diferentes, clases de referencias cruzadas, vea el historial de cambios y busque por nombre de clase, nombre de método, etc. Para obtener más información, consulte esta guía.

martes, 16 de julio de 2019

AI HUB despliega tu IA en tu empresa

AI Hub es una plataforma para descubrir e implementar productos que usan "Aprendizaje Automático", desde la experimentación hasta la producción.




AI Hub tu nuevo portal para todo lo que AI en su empresa, así como en general. Esta es una introducción a los diversos componentes que Google Cloud ofrece para que pueda escalar su implementación de IA.

Conozca cómo AI Hub fomenta la colaboración, el intercambio y la reutilización de los componentes de AI dentro de las empresas y sus colaboradores.

Experimente cómo puede aprovechar las mejores tecnologías y soluciones de inteligencia artificial de Google y desplegarlas en producción en GCP.

Empiza ahora mismo -> https://aihub.cloud.google.com/

martes, 2 de julio de 2019

Minikube vs Docker vs MicroK8s vs Minishift

 Certified Kubernetes  Resultado de imagen de kubernetes  Resultado de imagen de minikube

¿ Tenemos opciones para ejecutar Kubernetes en la nube y Kubernetes On-Prem?.
¿Qué hay de las opciones para ejecutar Kubernetes en el ordenador de escritorio y/o portátil?

Comparamos cuatro opciones que puedes elegir hoy. Minikube vs Docker Desktop vs MicroK8s vs Minishift.

Todas estas opciones están bastante diferenciadas. A diferencia de la variedad de soluciones de On-Prem Kubernetes, donde existen muchas sin ninguna razón, creo que hay un caso para la existencia de cada una de las opciones locales de Kubernetes que se están revisando.

Revisaremos cada uno de ellos y luego los resumiré con una tabla al final.

Minikube


Kubernetes fue construido por ingenieros de sistemas para ingenieros de sistemas. Minikube es la forma original de ejecutar Kubernetes localmente y, como puede imaginar, es la mejor opción actualmente para los ingenieros de sistemas. Si su compañía está ejecutando "Vanilla Kubernetes" ya sea en la versión local o a través de un servicio en la nube, y está en un rol de tipo SRE, entonces este es el recomendable..

Minikube funciona en todas las plataformas y te permite configurar muchas opciones. Si está ejecutando Linux, puedes desactivar la máquina virtual para que se ejecute de forma nativa.

La otra cosa interesante es que es compatible con todas las versiones de Kubernetes, por lo que puede hacer coincidir exactamente las versiones que está ejecutando en su ordenador portátil con la versión que está ejecutando en sus servidores.

Como perfil de tipo SRE, ejecuto Minikube localmente y también ejecutamos esto en CI build VM´s para pruebas de unidad en el trabajo.


Minikube
CompaniaCNCF
URLhttps://kubernetes.io/docs/setup/minikube/
Version KubernetesAny
Os soportadoOSX, Linux, Windows
Tipo contenedorLinux
VMNone, Virtualbox, VMWare fusion, KVM2, Hyperkit, xhyve, Hyper-V
Addonsaddon-manager, coredns, dashboard, default-storageclass, efk, freshpod, heapster, ingress, kube-dns, metrics-server, nvidia-driver-installer, nvidia-gpu-device-plugin, registry, registry-creds, storage-provisioner

Minikube
MejorLa mejor solución para los operadores de clústeres Kubernetes (DevOps / SRE) que desean practicar las tareas de administración de clústeres Kubernetes. Opciones de Kubernetes altamente configurables.
PeorVM separada en OSX y Windows. Más complejo que Docker Desktop para desarrolladores.

Docker Desktop

Este es el que recomendarás a tus equipos de desarrollo.
Todos los desarrolladores ya tendrán instalado Docker, por lo que habilitar a Kubernetes es tan simple como marcar una casilla de verificación.

 Kubernetes luego se ejecuta en la misma máquina virtual en Windows y OSX que Docker, lo que ahorra algunos recursos. Docker Desktop esconde gran parte de la complejidad de la administración de clústeres, lo cual es excelente si su objetivo es simplemente escribir aplicaciones y ejecutarlas.

El otro beneficio es que cuando ejecute Kubernetes en Docker Desktop, sus aplicaciones compartirán el mismo registro de imágenes entre Docker y Kubernetes.

Hay otra razón convincente para usar Docker Desktop. Si está utilizando Windows y desea utilizar contenedores de Windows, esta es la única opción que lo admite. Tenga en cuenta que esto no funciona bien con la virtualización no nativa. (Debes deshabilitar cualquier VirtualBox y usar solo HyperV.)



Docker Desktop
CompaniaDocker
URLhttps://www.docker.com/products/docker-desktop
Version KubernetesHardcoded to Docker
Os soportadoOSX, Windows
Tipo contenedorLinux (on OSX), Linux or Windows (on Windows)
VMHyperkit, Hyper-V
Addons-

Docker Desktop
MejorLa mejor solución para desarrolladores que quieran construir aplicaciones localmente. La única solución en Windows que ejecutará contenedores de Windows. Se ejecuta en la misma máquina virtual que Docker. Las imágenes comparten el mismo registro local.
PeorKubernetes no es tan configurable como las otras opciones. Si eres un SRE utiliza Minikube.
-->

MicroK8s

Esto es de Canonical, esperamos que esté realmente diseñado para la gente de Ubuntu.

Aunque, es compatible con cualquier sistema que pueda usar paquetes Snap. Hay algunos beneficios inherentes de usar una aplicación instalada de Snap relacionada con el sandboxing y la desinstalación limpia. MicroK8s realiza un seguimiento de Kubernetes en sentido ascendente y ofrece canales estables y beta.

Tampoco requiere ninguna máquina virtual, que es similar a la ejecución de Minikube en Linux con vm-driver = none. Como MicroK8s solo se ejecuta en Linux, tiene menos base de usuarios.

También es la menos madura de todas las opciones y solo se lanzó en mayo de 2018. Si ya está utilizando paquetes Snap, esta puede ser una buena opción.

Probablemente seguiría con Minikube o Docker Desktop dependiendo de mi función, pero es bueno que exista otra opción para competir.


Minishift
CompaniaRedhat
URLhttps://www.okd.io/minishift/
Version KubernetesHardcoded to OKD
Os soportadoOSX, Linux, Windows
Tipo contenedorLinux
VMVirtualbox, xhyve, KVM, Hyper-V
Addonsanyuid, admin-user, registry-route, htpasswd-identity-provider, xpaas, che, community addons

Minishift
MejorLa mejor solución para operadores y desarrolladores que utilizan OpenShift en su empresa.
PeorSi está ejecutando Kubernetes que no son OpenShift en su empresa, vaya con otra opción.
-->

MiniShift

Es la opción para las personas que trabajan para compañías que han comprado en OpenShift y, por lo tanto, usar Minishift localmente es la mejor opción.

Creo que tendría sentido utilizar Minishift independientemente de su función si ya está en esta plataforma en caso de que haya alguna diferencia.


Minishift
CompaniaRedhat
URLhttps://www.okd.io/minishift/
Version KubernetesHardcoded to OKD
Os soportadoOSX, Linux, Windows
Tipo contenedorLinux
VMVirtualbox, xhyve, KVM, Hyper-V
Addonsanyuid, admin-user, registry-route, htpasswd-identity-provider, xpaas, che, community addons

Minishift
MejorLa mejor solución para operadores y desarrolladores que utilizan OpenShift en su empresa.
PeorSi está ejecutando Kubernetes que no son OpenShift en su empresa, vaya con otra opción.