This api could be deployed to google cloud function?
https://github.com/Mdsp9070/someoneFlix/tree/master/backend
I tried to deploy but I'm getting this error:
ERROR: (gcloud.functions.deploy) OperationError: code=3, message=Build failed: main.go:16:2: import "flix-api.localhost/flix-api" is a program, not an importable package; Error ID: 975560ac
You have to implement the correct signature to handle functions requests
func myFunction(w http.ResponseWriter, r *http.Request) {
...
}
Here you start you own web server with several endpoint. It's not a Cloud Functions pattern, but more a Cloud Run service. Try this (with the correct ProjectID)
gcloud alpha builds submit --pack=image=gcr.io/PROJECT_ID/backend && \
gcloud run deploy --platform=managed --region=us-central1 --image=gcr.io/PROJECT_ID/backend --port=3333 --allow-unauthenticated backend
And call the url provided. I tested with your code and it worked on my side, I just got an error in the logs Error on loadinf .env file. You might have --set-env-vars to set to add environment variables.
If interested, I can explain more the commands
EDIT
Some explanations
Cloud Functions and Cloud Build share the same backend. Cloud Run host a webserver (in a customizable container). CLoud Function package the function into a webserver (that's why you have to respect a function signature to make it callable by the generic webserver).
Cloud Run can handle concurrent requests in the same instance (up to 80), Cloud Functions only 1. You can have the exact same behavior if you set the Cloud Run concurrency param to 1
Cloud Run need a container. When you have your code, you can write a Dockerfile (you can find examples in the documentation). You can build the container with Cloud Build or with Docker build. In my code example, I used an alpha (and not documented command) of Cloud Build based on Buildpack project. Build pack detect your language, the main file and create automatically a standard container based on your code. Perfect for a quick test and containers that don't required customization.
Related
No clear path to do development in a serverless environment.
I have an API Gateway backed by some Lambda functions declared in Terraform. I deploy to the cloud and everything is fine, but how do I go about setting a proper workflow for development? It seems like a struggle to push every small code change to the cloud while developing in order to run your code. Terraform has started getting some support by the SAM framework to run your Lambda functions locally (https://aws.amazon.com/blogs/compute/better-together-aws-sam-cli-and-hashicorp-terraform/), but still no way to simulate a local server and test out your endpoints in Postman for example.
First of all I use serverless plugin instead of terraform, my answer is based on what you provided and what I found around.
From what I understood so far with priovided documentation you are able to run sam CLI with terraform (cf: Chapter Local testing)
You might follow this documentation to invoke local functions.
I recommend to use JSON files to create use cases instead of stdin injection.
First step is to create your payload in json file and to invoke your lambda with the json payload like
sam local invoke "YOUR_LAMBDA_NAME" -e ./path/to/yourjsonfile.json
I have just started developing a Golang app, and have deployed it on Google App Engine. But, when I try to connect my local server to CloudSQL instance through proxy, I am able to connect only through TCP.
However, when connecting with the same CloudSQL instance in AppEngine, I am able to connect only through UNIX.
To cope with this, I have made changes in my local environment handler file, so that it can adapt to local and GCloud config, but I'm not sure how I can skip the update on just this file for GCloud? Again, I don't want AppEngine to delete this file, I just want the CLI to avoid uploading the new version of the handler file.
I use this command for deploying: gcloud app deploy
Currently, I deploy directly to AppEngine, instead of pushing it through VCS. Also, if there is an option to detect if the app is running on AppEngine, then it'd be really great.
TIA
Got it, in case anyone gets stuck in such situation, we can make use of environment variables set in GCloud AppEngine. Although there is documentation stating the environment variables, I would still give importance to checking the environment variables in Cloud Console.
Documentation link for Go 1.12+ Runtime env:
https://cloud.google.com/appengine/docs/standard/go/runtime
Iam looking for help to containerize a laravel application with docker, running it locally and make it deployable to gcloud Run, connected to a gcloud database.
My application is an API, build with laravel, and so far i have just used the docker-compose/sail package, that comes with laravel 8, in the development.
Here is what i want to achieve:
Laravel app running on gcloud Run.
Database in gcloud, Mysql, PostgreSQL or SQL server. (prefer Mysql).
Enviroment stored in gcloud.
My problem is can find any info if or how to use/rewrite the docker-composer file i laravel 8, create a Dockerfile or cloudbuild file, and build it for gcloud.
Maybe i could add something like this in a cloudbuild.yml file:
#cloudbuild.yml
steps:
# running docker-compose
- name: 'docker/compose:1.26.2'
args: ['up', '-d']
Any help/guidanceis is appreciated.
As mentioned in the comments to this question you can check this video that explains how you can use docker-composer, laravel to deploy an app to Cloud Run with a step-by-step tutorial.
As per database connection to said app, the Connecting from Cloud Run (fully managed) to Cloud SQL documentation is quite complete on that matter and for secret management I found this article that explains how to implement secret manager into Cloud Run.
I know this answer is basically just links to the documentation and articles, but I believe all the information you need to implement your app into Cloud Run is in those.
I have created a Zend expressive application that basically exposes a few APIs. I want to deploy this now to AWS Lambda. What is the best way to refactor the code quickly and easily (or is there any other alternatives) to deploy it? I am fairly new in AWS.
I assume that you have found the answer already since the question is more than five months old. But I am posting what I have found in my recent research in the same criteria. Please note that you need to have at least some idea on how AWS IAM, Lambda, API Gateway in order to follow the steps I have described below. Also please note that I have only deployed the liminas/mezzio skeleton app during this research and you'll need much more work to deploy a real app because it might need database & storage support in the AWS environment which might require to adapt your application accordingly.
PHP application cab be executed using the support for custom runtimes in AWS. You could check this AWS blog article on how to get it done but it doesn't cover any specific PHP framework.
Then I have found this project which provides all then necessary tools for running a PHP application in serverless environment. You could go through their documentation to get an understanding how things work.
In order to get the liminas/mezzio (new name of the zend expressive project) skeltopn app working, I have followed the laravel tutorial given in the bref documentation. First I installed bref package using
composer require bref/bref
Then I have created the serverless.yml file in the root folder of the project according to the documentation and made few tweaks in it and it looked like as follows.
service: myapp-serverless
provider:
name: aws
region: eu-west-1 # Change according to the AWS region you use
runtime: provided
plugins:
- ./vendor/bref/bref
package:
exclude:
- node_modules/**
- data/**
- test/**
functions:
api:
handler: public/index.php
timeout: 28 # in seconds (API Gateway has a timeout of 29 seconds)
memorySize: 512 # Memory size for the AWS lambda function. Default is 1024MB
layers:
- ${bref:layer.php-73-fpm}
events:
- http: 'ANY /'
- http: 'ANY /{proxy+}'
Then I followed the deployment guidelines given in the bref documentation which is to use serverless framework for the deployment of the app. You can check here how to install serverless framework on your system and here to see how it need to be configured.
To install servreless I have used npm install -g serverless
To configure the tool I have used serverless config credentials --provider aws --key <key> --secret <secret>. Please note that this key used here needs Administrator Access to the AWS environment.
Then serverless deploy command will deploy your application to the AWS enviroment.
The result of the above command will give you an API gateway endpoint with which you application/api will work. This is intended as a starting point for a PHP serverless application and there might be lots of other works needed to be done to get an real application working there.
I have moved parse sever from parse.com to heroku. Everything is working fine except cloud code('cloud/main.js' file).
I have replaced "main.js" of parse.com with "main.js" of parse server code and deployed on heroku, but it is not working. Getting following error when I make request from my mobile app
{"code":1,"message":"Internal server error."} (Code: 1, Version: x.xx.x)
Any idea?
Note:
I've followed following link for migrating parse server
https://learnappmaking.com/how-to-migrate-parse-app-parse-server-heroku-mongolab/
Migrating cloud code can range in difficulty depending on how involved that code is. Here's a workflow for validating your code:
1) Check that you can build your Heroku app locally with the right Node version.
2) Comment out all of your cloud code. You want to start introducing your code in parts and make sure it compiles with each re-introduced function.
3) Install the node modules for each service that you use. If you use stripe/mailgun or any other package, add them in your package.json file and run npm install. Then include them in your main.js file with the require('packageName').
4) The cloud server uses Express.js version 4.2 and a Parse.com runs Express version 2.0 or 3.0 but not 4.0. If you use any middlewear then you need to change it to the proper Express 4.0 syntax/methodology.
5) There is no support for cloud jobs so rename all your *.job functions to *.define and comment properly so you can come back to them later. If you did not use cloud jobs then don't worry.
6) If you did use cloud jobs, now you need to setup a heroku worker/scheduler to run those old *.job (now *.define) calls at the proper time intervals you had.