Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina descrive alcune informazioni che devi conoscere per iniziare a sviluppare un servizio per Knative serving.
Requisiti di codice
Quando sviluppi un servizio, devi soddisfare i seguenti requisiti:
Il servizio deve ascoltare le richieste.
Puoi configurare la porta su cui vengono inviate le richieste.
All'interno delle istanze di container di Knative serving, il valore della variabile di ambiente PORT riflette sempre la porta a cui vengono inviate le richieste.
Il codice deve verificare l'esistenza di questa variabile di ambiente PORT e, se è presente, deve eseguire le operazioni di ascolto su di essa per massimizzare la portabilità.
Il servizio deve essere stateless. Non può fare affidamento su uno stato locale persistente.
Il servizio non deve eseguire attività in background al di fuori dell'ambito della gestione delle richieste.
Knative Serving ti consente di scrivere codice nel linguaggio di programmazione che preferisci.
Utilizzo di un server web
Puoi utilizzare un server web per ascoltare sulla porta richiesta ed elaborare e indirizzare le richieste in arrivo. Ad esempio, gli sviluppatori Node.js possono utilizzare
Express.js, gli sviluppatori Python possono utilizzare
Flask, gli sviluppatori Ruby possono utilizzare
Sinatra e così via.
Containerizzazione del codice
Per eseguire il deployment in Knative serving, devi fornire un'immagine container.
Un'immagine container è un formato di pacchetti che include il codice, i relativi pacchetti, eventuali dipendenze binarie necessarie, il sistema operativo da utilizzare e tutto ciò che è necessario per eseguire il servizio.
Un file denominato Dockerfile viene spesso utilizzato per dichiarare come creare l'immagine container.
I file Docker iniziano molto spesso da un'immagine di base (ad es. FROM golang:1.11). Puoi trovare le immagini di base gestite dagli autori del sistema operativo e del linguaggio su Docker Hub. Cloud Build controlla la presenza di immagini memorizzate nella cache prima di eseguire il pull da Docker Hub. Se utilizzi uno strumento di compilazione di terze parti, puoi configurare il daemon Docker in modo che controlli la presenza di immagini nella stessa cache. Puoi anche trovare le immagini di base gestite da Google in Google Cloud Marketplace.
Se fornisci i tuoi binari, assicurati che siano compilati per l'ABI x86_64 di Linux.
Queste risorse forniscono ulteriori informazioni sui file Dockerfile:
Per le best practice per la progettazione, l'implementazione, il test e il deployment di un servizio
in Knative serving, consulta i suggerimenti per lo sviluppo.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-01 UTC."],[],[],null,["# Developing your service\n\nThis page describes a few things you need to know to get started in developing\na service for Knative serving.\n\nCode requirements\n-----------------\n\nYou must meet the following requirements when you develop a service:\n\n- The service must listen for requests. You can [configure the port](/kubernetes-engine/enterprise/knative-serving/docs/configuring/containers#configure-port) on which requests are sent. Inside Knative serving container instances, the value of the `PORT` environment variable always reflects the port to which requests are sent. Your code should check for the existence of this `PORT` environment variable and if it is present, should listen on it to maximize portability.\n- The service must be *stateless* . It cannot rely on a persistent **local** state.\n- The service must not perform background activities outside the scope of request handling.\n\nYou can find more details about these constraints in the [Container Runtime Contract](/kubernetes-engine/enterprise/knative-serving/docs/reference/container-contract).\n\nProgramming language support\n----------------------------\n\nKnative serving allows you to write code in the programming language of\nyour choice.\n\nUsing a web server\n------------------\n\nYou can use a web server to listen on the required port, and to process and\nroute incoming requests. For example, Node.js developers can use\n[Express.js](https://expressjs.com/), Python developers can use\n[Flask](http://flask.pocoo.org/), Ruby developers can use\n[Sinatra](http://sinatrarb.com/), and so forth.\n\nContainerizing your code\n------------------------\n\nTo deploy to Knative serving, you need to provide a *container image*.\nA container image is a packaging format that includes your code, its\npackages, any needed binary dependencies, the operating system to use, and\nanything else needed to run your service.\n\nA file named [Dockerfile](https://docs.docker.com/engine/reference/builder/) is\ncommonly used to declare how to build the container image.\n\nDockerfiles very often start from a base image (e.g. `FROM golang:1.11`).\nYou can find base images maintained by OS and language authors on\n[Docker Hub](https://hub.docker.com/). Cloud Build checks for [cached images](/container-registry/docs/pulling-cached-images) before pulling from Docker Hub. If you use a third-party build\ntool, you can configure your Docker daemon to check for images in the same\ncache. You can also find base images managed by Google in the\n[Google Cloud Marketplace](https://console.cloud.google.com/marketplace/browse?filter=solution-type:container&filter=category:os).\n| **Note:** As of November 1, 2020, Docker Hub\n| [rate limits](https://www.docker.com/blog/scaling-docker-to-serve-millions-more-developers-network-egress/) apply to unauthenticated or authenticated pull requests on the\n| Docker Free plan. To avoid disruptions and have greater control over your\n| software supply chain, you can migrate your dependencies to [Artifact Registry](/artifact-registry/docs/docker/migrate-external-containers).\n\nIf you bring your own binaries, make sure they are compiled for Linux ABI x86_64.\n\nThese resources provide further information on Dockerfiles:\n\n- Learn Dockerfile syntax through the [Dockerfile reference](https://docs.docker.com/engine/reference/builder).\n- Learn how Dockerfiles fit together through the tips in [Best practices for writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/).\n\nWhat's next\n-----------\n\n- Once you have your service code and Dockerfile, you should [build a container image](/kubernetes-engine/enterprise/knative-serving/docs/building/containers) then continue iterating in [local testing](/kubernetes-engine/enterprise/knative-serving/docs/testing/local).\n- If you are migrating an existing web application, see [Migrating Your Service to Knative serving](/kubernetes-engine/enterprise/knative-serving/docs/migrating).\n- For best practices for designing, implementing, testing, and deploying a service in Knative serving, see the [Development tips](/kubernetes-engine/enterprise/knative-serving/docs/tips/general)."]]
