I usually deploy my NodeJS app to Google App Engine and ignore all docker assets when deploying by a .gcloudignore file as below:
.git
.gitignore
Dockerfile
docker-compose.yml
nginx/
redis-data/
.vscode/
.DS_Store
.prettierrc
README.md
node_modules/
.env
Last week I have successfully deployed my app to App Engine without any problems. But today (without any changes except source code) it failed and threw me an Error:
ERROR: (gcloud.app.deploy) There is a Dockerfile in the current directory, and the runtime field in /Users/tranphongbb/Works/unstatic/habitify-annual-report-backend/app.yaml is currently set to [runtime: nodejs]. To use your Dockerfile to build a custom runtime, set the runtime field to [runtime: custom]. To continue using the [nodejs] runtime, please remove the Dockerfile from this directory.
Even when removing the .gcloudignore file and go with the skip_files option in app.yaml, it still failed.
My source tree:
.dockerignore
.eslintrc.json
.gcloudignore
.gitignore
.prettierrc
.vscode
Dockerfile
README.md
app.yaml
docker-compose.yml
nginx
package.json
src
I reproduced your issue by cloning both Node.js App Engine Flex Quickstart and adding a Dockerfile to the same folder as the app.yaml file.
Indeed, I received the same error message as you did. But I was able to see that if I move the Dockerfile to a different directory, the deploy succeeds. It seems that gcloud app deploy doesn't respect the .gcloudignore file.
For node.js in the Flexible Environment, there’s no skip_files entry in the App Engine Official Documentation.
To ignore your files defined in .gcloudignore file, please run the command gcloud beta app deploy which worked for me to ignore the Dockerfile when using Nodejs Runtime in app.yaml or you can use gcloud app deploy command but move your Dockerfile to another directory.
The purpose of the .gcloudignore file is to avoid certain files to be uploaded to App Engine, Cloud Functions, etc, deployments which is documented here. When using gcloud app deploy this command will notice if there is a Dockerfile and will correlate that in the app.yaml there is set runtime: custom. In case that condition is not meet, you'll get a similar error message as follows:
ERROR: (gcloud.app.deploy) There is a Dockerfile in the current directory, and the runtime field in path/app.yaml is currently set to [runtime: nodejs]. To use your Dockerfile to build a custom runtime, set the runtime field to [runtime: custom]. To continue using the [nodejs] runtime, please remove the Dockerfile from this directory.
Now the last question, why does this work with gcloud beta app deploy and not with gcloud app deploy?
Checking at the source code of the Cloud SDK which can be viewed by anyone, the gcloud app deploy has the following code which makes the verification mentioned before:
if info.runtime == 'custom':
if has_dockerfile and has_cloudbuild:
raise CustomRuntimeFilesError(
('A custom runtime must have exactly one of [{}] and [{}] in the '
'source directory; [{}] contains both').format(
config.DOCKERFILE, runtime_builders.Resolver.CLOUDBUILD_FILE,
source_dir))
elif has_dockerfile:
log.info('Using %s found in %s', config.DOCKERFILE, source_dir)
return False
elif has_cloudbuild:
log.info('Not using %s because cloudbuild.yaml was found instead.',
config.DOCKERFILE)
return True
else:
raise NoDockerfileError(
'You must provide your own Dockerfile when using a custom runtime. '
'Otherwise provide a "runtime" field with one of the supported '
'runtimes.')
else:
if has_dockerfile:
raise DockerfileError(
'There is a Dockerfile in the current directory, and the runtime '
'field in {0} is currently set to [runtime: {1}]. To use your '
'Dockerfile to build a custom runtime, set the runtime field to '
'[runtime: custom]. To continue using the [{1}] runtime, please '
'remove the Dockerfile from this directory.'.format(info.file,
On the other hand the gcloud beta app deploy does not do this verification at all (assuming I reviewed the correct code):
if runtime == 'custom' and self in (self.ALWAYS,
self.WHITELIST_BETA,
self.WHITELIST_GA):
return needs_dockerfile
In conclusion, the .gcloudignore will prevent some files/folder to be uploaded but not will be considered when doing some pre-checks of this command. In this case a Dockerfile should be considered since it could be part of the deployment.
Related
Currently I'm trying to breakdown my serverless service into multiple services to get over the cloudFormation resource limit.
My current project structure is as follows:
aws-backend
functions
workers
serverless.yml // workers service
.env.local
.env.dev
serverless.yml // Rest of the functions in here
In my workers service, I'm trying to reference the .env.* files in the root folder using variables.
My issue is when i use the following syntax
${env:SLS_AWS_REGION}
I get a
Error:Cannot resolve serverless.yml: Variables resolution errored with:
- Cannot resolve variable at "provider.region": Value not found at "env" source
but when I use the following syntax:
${../../env:SLS_AWS_REGION}
It works but I get a warning:
Warning: Invalid configuration encountered
at 'package.individually': must be boolean
at 'provider.region': must be equal to one of the allowed values [use-east-1, etc...]
How can I get rid of this error? Am I even using the correct syntax?
Thanks
as for this error
Error:Cannot resolve serverless.yml: Variables resolution errored with:
- Cannot resolve variable at "provider.region": Value not found at "env" source
You get this error because the Framework cannot find SLS_AWS_REGION environment variable. The env variable source doesn't read from .env files, but from environment variables from the process.
As for this syntax:
${../../env:SLS_AWS_REGION}
This does not work because env is a correct variable source, not ../../env.
You have two options here:
Ensure that content of the .env file(s) is exported so the variables defined in these files are actually exported as environment variables before running serverless commands.
Set useDotenv: true in your serverless.yml file so the .env files will be loaded automatically with dotenv. Please see the docs for reference on how it works: https://www.serverless.com/framework/docs/environment-variables
According to the plugin documentation, you should run sls deploy with --stage or --env (deprecated in Serverless >=3.0.0) or NODE_ENV corresponding to the .env file name. If you run it without any of those flags, it will default to development, and the plugin will look for the plugin will look for files named .env, .env.development, .env.development.local
Note that Serverless Framework .env files resolution works differently to the plugin.
The framework looks for .env and .env.{stage} files in service directory and then tries to load them using dotenv. If .env.{stage} is found, .env will not be loaded. If stage is not explicitly defined, it defaults to dev.
I believe the plugin takes precedence here.
I am trying to read .env file using "dotenv" package but it returns undefined from process.env.DB_HOST after published to gcloud run. I see all files except for the .env file in root directory when I output all files to log. I do have .env file in my project on a root directory. Not sure why it's not getting pushed to gcloud or is it?. I do get a value when I tested locally for process.env.DB_HOST.
I used this command to publish to google run.
gcloud builds submit --tag gcr.io/my-project/test-api:1.0.0 .
If you haven't a .gcloudignore file in your project, gcloud CLI use the .gitignore by default
Create a .gcloudignore and put the file that you don't want to upload when you use gcloud CLI command. So, don't put the .env in it!
EDIT 1
When you add a .gcloudignore, the gcloud CLI no longer read the .gitignore file and use it instead.
Therefore, you can define 2 different logics
.gitignore list the file that you don't want to push to the repository. Put the .env file in it to NOT commit it
.gcloudignore list the file that you don't want to send with the gcloud CLI. DON'T put the .env file in it to include it when you send your code with the gcloud CLI
I have a simple, static website that I'm attempting to deploy as an Azure Static Web App (no framework) using GitHub Actions. My directory structure is:
├── .github/workflows/
├── css/
├── img/
├── js/
├ index.html
When I make a push to the GitHub repo, the Azure Static Web Apps CI/CD action starts the build & deploy job. In my YAML configuration file in the .github/workflows directory, I have set the following for my Repository/Build Configuration:
app_location: "/" # The app source code is in the root directory for the repo
api_location: "" # There is no API that needs to be configured
output_location: "/" # my index.html file is in the root directory for the repo
However, I get the following error in my Build and Deploy Job:
Failed to find a default file in the app artifacts folder (/). Valid
default files: index.html,Index.html. If your application contains
purely static content, please verify that the variable 'app_location'
in your workflow file (located in .github/workflows) points to the root of your application.
Why am I getting this error when I've specified where the index.html file is?
Because the deploy container was based on Ubuntu, I guessed that the output location may be getting confused with the root directory for the entire system.
So, I set the output location in the workflow YAML file to:
output_location: "./"
With that change, the build completes and the static web app deploys successfully.
I have the same problem,
I tried to run this command locally:
`npm run build`
then I checked the root folder of the app to find what is the name of the build folder and it fixed my problem.
I am trying to deploy a sample python app which I got from another tutorial. However, the deployment fails as below:
gcloud app deploy Beginning deployment of service [default]... ERROR:
gcloud crashed (FileNotFoundError): [Errno 2] No such file or
directory:
'/Users/nileshdeshmukh/Desktop/Training/Python/FlaskIntroduction-master/env/.Python'
My app.yaml file is as below:
runtime: python3
env: standard
runtime_config:
python_version: 3
I have all dependencies copied in env/bin but the build process is looking for env only..
I think the problem would be solved if the deployment process looks at env/bin, but don't know how to force it to look at given path
The runtime_config setting is for App Engine flex only and isn't needed for App Engine Standard. You can safely remove it.
As per the error, you should ensure that all your dependencies are self-contained and shipped with your app or listed in your requirements.txt file.
Be careful, some gcloud commands use .gitignore file to prevent sending useless file to Cloud for building your app.
You can override this behavior by creating a .gcloudignore file. Same syntax as git ignore but take into account only by gcloud commands and not by git. By the way you can differentiate the file to send to the cloud and file to send to git
I get this error every time I run the gcloud app deploy command.
My app.yaml is in the same directory as where manage.py is.
I am also not working from Local disk C, am working from Local disk G and using Visual studio code cmd terminal.
ERROR: An app.yaml (or appengine-web.xml) file is required to deploy this directory as an App Engine application. Create an app.yaml file using the directions at https://cloud.google.com/appengine/docs/flexible/python/configuring-your-app-with-app-yaml (App Engine Flexible Environment) or https://cloud.google.com/appengine/docs/standard/python/config/appref (App Engine Standard Environment) under the tab for your language.
ERROR: (gcloud.app.deploy) [G:\] could not be identified as a valid source directory or file.
From what I can understand, you are running the "gcloud app deploy" command from the main folder of your G: local disk.
In order to deploy the app, your path should be the one that the app.yaml file is in or specify the path as a parameter as shown here in the first example when you run the "gcloud app deploy".
You are wrong the directory.
To make sure app.yaml path, you can include it into command line as below:
gcloud --quiet --project $PROJECT_ID app deploy app.yaml