Migrar de Go 1.11 al entorno de ejecución de Go más reciente

En esta página se explica cómo migrar de los entornos de ejecución de Go de primera generación a los de segunda generación. Para actualizar tu aplicación de segunda generación a la versión más reciente compatible de Go, consulta Actualizar una aplicación.

Go 1.11 llegó al final del ciclo de asistencia el 30 de enero del 2024. Tus aplicaciones de Go 1.11 seguirán ejecutándose y recibiendo tráfico. Sin embargo, App Engine puede bloquear el nuevo despliegue de aplicaciones que usen tiempos de ejecución después de la fecha de finalización de su asistencia. Te recomendamos que migres al runtime compatible más reciente de Go siguiendo las directrices de esta página.

Si migras a un runtime de Go de segunda generación compatible, podrás usar funciones de lenguaje actualizadas y crear aplicaciones más portátiles con código idiomático.

Cambios en los tiempos de ejecución de la segunda generación

Ten en cuenta las siguientes diferencias al actualizar a un tiempo de ejecución de Go de segunda generación compatible:

• Para reducir el esfuerzo y la complejidad de la migración del tiempo de ejecución, el entorno estándar de App Engine te permite acceder a muchos de los servicios y APIs antiguos incluidos en los tiempos de ejecución de segunda generación, como Memcache. Tu aplicación Go de segunda generación puede llamar a las APIs de los servicios incluidos a través del SDK de App Engine para Go y acceder a la mayoría de las mismas funciones que en el tiempo de ejecución de Go 1.11.

  También puedes usar Google Cloud productos que ofrecen funciones similares a los servicios antiguos agrupados. Estos productos proporcionan bibliotecas de cliente de Cloud idiomáticas para Go. En el caso de los servicios incluidos que no están disponibles como productos independientes enGoogle Cloud, como el procesamiento de imágenes, la búsqueda y la mensajería, puedes usar proveedores externos u otras soluciones alternativas. Google Cloud

  Para obtener más información sobre cómo migrar a servicios independientes, consulta el artículo Migrar de servicios agrupados.

• Se ha modificado el comportamiento de algunos elementos del archivo de configuración app.yaml. Para obtener más información, consulta Cambios en el archivo app.yaml.

• El registro en el tiempo de ejecución de segunda generación sigue el estándar de registro de Cloud Logging. En los tiempos de ejecución de segunda generación, los registros de aplicaciones ya no se incluyen en los registros de solicitudes, sino que se separan en registros diferentes. Para obtener más información sobre cómo leer y escribir registros en los tiempos de ejecución de segunda generación, consulta la guía de registro.

Diferencias en el uso de memoria

Los tiempos de ejecución de segunda generación tienen un uso de memoria de referencia más alto que los de primera generación. Esto se debe a varios factores, como las diferentes versiones de la imagen base y las diferencias en la forma en que las dos generaciones calculan el uso de memoria.

Los tiempos de ejecución de segunda generación calculan el uso de memoria de las instancias como la suma de lo que usa un proceso de aplicación y el número de archivos de aplicación almacenados dinámicamente en caché en la memoria. Para evitar que las aplicaciones que consumen mucha memoria experimenten cierres de instancias debido a que superan los límites de memoria, cambia a una clase de instancia más grande con más memoria.

Diferencias en el uso de la CPU

Los tiempos de ejecución de segunda generación pueden experimentar un aumento del uso de la CPU al iniciar una instancia por primera vez. En función de la configuración de escalado de una aplicación, esto puede tener efectos secundarios no deseados, como un número de instancias superior al previsto si una aplicación está configurada para escalarse en función de la utilización de la CPU. Para evitar este problema, revisa y prueba las configuraciones de escalado de la aplicación para asegurarte de que el número de instancias sea aceptable.

Diferencias en los encabezados de solicitud

Los tiempos de ejecución de primera generación permiten que los encabezados de solicitud con guiones bajos (por ejemplo, X-Test-Foo_bar) se reenvíen a la aplicación. Los runtimes de segunda generación introducen Nginx en la arquitectura del host. Como resultado de este cambio, los tiempos de ejecución de segunda generación se configuran para eliminar automáticamente los encabezados con guiones bajos (_). Para evitar problemas con las aplicaciones, no utilices guiones bajos en los encabezados de las solicitudes de las aplicaciones.

Cambios en el archivo app.yaml

Se ha modificado el comportamiento de algunos elementos del archivo de configuración app.yaml:

Para obtener más información, consulta la referencia de app.yaml.

Crear un paquete main

Tu servicio debe incluir una instrucción package main en al menos un archivo de origen.

Servicios agrupados antiguos de App Engine

Si tu servicio usa los servicios agrupados antiguos para los runtimes de segunda generación, haz lo siguiente:

• Tu servicio solo debe usar paquetes de la versión 2 (google.golang.org/appengine/v2). Si se usan los paquetes de la versión anterior v1 (google.golang.org/appengine), se producen errores.

• En tu función main(), llama a appengine.Main() en lugar de http.ListenAndServe(). De esta forma, las APIs user y appengine tienen acceso al contexto de la solicitud actual.

Escribir un paquete principal

Si tu servicio aún no contiene un paquete main, añade la instrucción package main y escribe una función main(). Como mínimo, la función main() debe hacer lo siguiente:

• Lee la variable de entorno PORT y llama a la función http.ListenAndServe():

  port := os.Getenv("PORT")
  if port == "" {
  	port = "8080"
  	log.Printf("Defaulting to port %s", port)
  }
  
  log.Printf("Listening on port %s", port)
  if err := http.ListenAndServe(":"+port, nil); err != nil {
  	log.Fatal(err)
  }

Registrar controladores HTTP

Puedes registrar tus controladores HTTP eligiendo una de las siguientes opciones:

• El método preferido es mover manualmente todas las llamadas http.HandleFunc() de tus paquetes a la función main() de tu paquete main.

• También puedes importar los paquetes de tu aplicación en el paquete main y asegurarte de que cada función init() que contenga llamadas a http.HandleFunc() se ejecute al inicio.

  Puedes encontrar todos los paquetes que usan la llamada http.HandleFunc() con la siguiente secuencia de comandos de bash y copiar el resultado en el bloque import de tu paquete main:

  gp=$(go env GOPATH) && p=$(pwd) && pkg=${p#"$gp/src/"} && find . -name "*.go" | xargs grep "http.HandleFunc" --files-with-matches | grep -v vendor/ | grep -v '/main.go' | sed "s#\./\(.*\)/[^/]\+\.go#\t_ \"$pkg/\1\"#" | sort | uniq
  

Estructurar los archivos

Go requiere que cada paquete tenga su propio directorio. Puedes indicar a App Engine dónde se encuentra tu paquete main mediante main: en el archivo app.yaml de tu proyecto. Por ejemplo, si la estructura de archivos de tu aplicación fuera la siguiente:

myapp/
├── app.yaml
├── foo.go
├── bar.go
└── web/
    └── main.go

Tu archivo app.yaml incluiría lo siguiente:

main: ./web # Relative filepath to the directory containing your main package.

Para obtener más información sobre la marca main, consulta la app.yaml referencia.

Mover archivos a tu GOPATH

Para encontrar tu GOPATH, usa el siguiente comando:

go env GOPATH

Mueve todos los archivos e importaciones pertinentes a tu GOPATH. Si usas importaciones relativas, como import ./guestbook, actualiza tus importaciones para que usen la ruta completa: import github.com/example/myapp/guestbook.