flyctl launch: Error name argument or flag must be specified when not running interactively - deployment

I am trying to deploy a flask app in fly.io, but when execute flyctl launch in the terminal I get an error:
Error name argument or flag must be specified when not running interactively.
I don't see any other way to make a deployment in fly.io other than the console. I tried with a Dockerfile but flyctl launch continue throwing the same error.

Apparently flyctl believes you're not running its command-line tool interactively. That may or may not be a bug of flyctl itself, you can ask about that in the fly.io community.
The solution to this problem is to add the required information as parameters instead of being prompted for data entry. To my knowledge, you only need the name of the app you want to launch and the region code of the server location. The syntax for that can be found using the fly help launch command:
λ flyctl help launch
Create and configure a new app from source code or a Docker image.
Usage:
flyctl launch [flags]
Flags:
--auto-confirm Will automatically confirm changes when running non-interactively.
--build-arg strings Set of build time variables in the form of NAME=VALUE pairs. Can be specified multiple times.
--build-only Build but do not deploy
--build-secret strings Set of build secrets of NAME=VALUE pairs. Can be specified multiple times. See https://docs.docker.com/develop/develop-images/build_enhancements/#new-docker-build-secret-information
--build-target string Set the target build stage to build if the Dockerfile has more than one stage
--copy-config Use the configuration file if present without prompting
--detach Return immediately instead of monitoring deployment progress
--dockerfile string Path to a Dockerfile. Defaults to the Dockerfile in the working directory.
--dockerignore-from-gitignore If a .dockerignore does not exist, create one from .gitignore files
-e, --env strings Set of environment variables in the form of NAME=VALUE pairs. Can be specified multiple times.
--generate-name Always generate a name for the app, without prompting
-i, --image string The Docker image to deploy
--image-label string Image label to use when tagging and pushing to the fly registry. Defaults to "deployment-{timestamp}".
--local-only Only perform builds locally using the local docker daemon
--name string Name of the new app
--nixpacks Deploy using nixpacks to generate the image
--no-cache Do not use the build cache when building the image
--no-deploy Do not prompt for deployment
--now Deploy now without confirmation
-o, --org string The target Fly organization
--path string Path to the app source root, where fly.toml file will be saved (default ".")
--push Push image to registry after build is complete
-r, --region string The target region (see 'flyctl platform regions')
--remote-only Perform builds on a remote builder instance instead of using the local docker daemon
--strategy string The strategy for replacing running instances. Options are canary, rolling, bluegreen, or immediate. Default is canary, or rolling when max-per-region is set.
Global Flags:
-t, --access-token string Fly API Access Token
-j, --json json output
--verbose verbose output
In summary, the following command, executed in the directory of the app you want to launch on fly.io, should create an app called your-app-name in the Toronto, Canada location.
flyctl launch --name your-app-name --region yyz

Related

Dockerfile ENV lost in container when deployed to Kubernetes

For years we have built base PHP-FPM container images locally with code like this to include Oracle DB support:
ARG PHP_VERSION=7.4
ARG PHP_TYPE=fpm
FROM php:${PHP_VERSION}-${PHP_TYPE}
ENV LD_LIBRARY_PATH /usr/local/instantclient
ENV ORACLE_BASE /usr/local/instantclient
ENV ORACLE_HOME /usr/local/instantclient
ENV TNS_ADMIN /etc/oracle
COPY oracle /etc/oracle
RUN echo 'instantclient,/usr/local/instantclient' | pecl install oci8-${OCI8_VERSION} \
&& docker-php-ext-configure oci8 --with-oci8=instantclient,/usr/local/instantclient \
&& docker-php-ext-install oci8 \
&& docker-php-ext-configure pdo_oci --with-pdo-oci=instantclient,/usr/local/instantclient \
&& docker-php-ext-install pdo_oci \
&& rm -rf /tmp/pear
From this image we build application specific images that are deployed to a Kubernetes cluster and the TNS_ADMIN variable and value have persisted without issue.
We recently changed how the images are built (using Kaniko and GitLab CI instead of building them locally) and found that now when the image is deployed to the Kubernetes cluster (via Helm) the TNS_ADMIN variable is now missing (not just a blank value, the entire variable). Another change made was how the Oracle pieces are installed (using docker-php-extension-installer), so the pertinent Dockerfile code looks like this now:
ADD https://github.com/mlocati/docker-php-extension-installer/releases/latest/download/install-php-extensions /usr/local/bin/
RUN chmod +x /usr/local/bin/install-php-extensions && \
install-php-extensions oci8 pdo_oci
# Oracle client config
ENV TNS_ADMIN=/etc/oracle
COPY php.cli/oracle /etc/oracle
And, here is the GitLab CI Kaniko related code to build the application specific images (only the $PHP_TYPE applies to the image in question):
- |
LOCAL_REPOSITORY=${CI_REGISTRY}/<internal namespace path>/$REPOSITORY
# Build config.json for credentials
echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
/kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/$DOCKER_FILE_PATH/Dockerfile --build-arg PHP_VERSION=$PHP_VERSION --build-arg PHP_TYPE=$PHP_TYPE --build-arg PHPUNIT_VERSION=$PHPUNIT_VERSION --build-arg PHPCS_VERSION=$PHPCS_VERSION --build-arg PHPCSFIXER_VERSION=$PHPCSFIXER_VERSION --destination $LOCAL_REPOSITORY:$PHP_VERSION-$TAG_NAME
Thinking this was possibly due to how Kaniko works, or the changes to the Oracle install process, we pulled the base image and application image separately and ran them with a bash shell. When pulled locally, the TNS_ADMIN variable is present. This suggests whatever is occurring is happening once Helm deploys it to the cluster.
What is vexing is on the surface neither of the changes we made should affect the setting of an environment variable in this manner in the image, but those were the only changes made that coincide with the issue arising. So, the issue seems to be when deploying the image to our cluster. This process itself has not changed at all. The Helm chart has not changed, which indicates it is not part of this issue; that being said, the issue occurs when Helm deploys the chart that uses the image.
Has anyone else seen something like this, or have any ideas where to center our search for answers?
Well, our issue was one that is probably endemic to many people running applications in Kubernetes: our image pull policy for the Helm deployment was set to IfNotPresent and a cached image without the ENV value set was being used (the image was built using a Dockerfile that did not set TNS_ADMIN). We have a lot of moving parts in our process and made multiple changes that were not seen due to this.
I am of course chastened by this explanation and so I will offer the advice to always make sure you are pulling a fresh image as the first step in troubleshooting issues with Kubernetes/Helm deployments.

devcontainers without VS Code?

Let's say that for some reason I don't want to launch VSC to get a devcontainer shell running, but I still want all of that devcontainer goodness without rewriting all of the configuration files. There's a devcontainer CLI, but at the moment, the only options available are open (VSC, connected to the container) and build (which builds the image, in the use case that many people are sharing the same devcontainer environment).
Ideally, there'd be a third option devcontainer shell which does all the build, spin up and connection work that is done inside VSC, but the just execs to the running container.
The .devcontainer folder contains a devcontainer.json file. In it, if you're using docker-compose, there will be a dockerComposeFile key with an array of docker-compose files, loaded in order. You can do the same with a command such as docker-compose -f first-compose-file.yml -f second-compose-file.yml.
That same folder usually has its own docker-compose.yml file. You will notice it declares your main service and usually sets up a volume to share between the host and the container (useful to work inside the container).
There are other interesting keys in devcontainer.json such as forwardPorts, remoteUser or postCreateCommand. You should be able to set up most of them in your docker-compose file (dev stuff should go into the .devcontainer/ one). The post-create command can be run with docker compose exec SERVICENAME COMMAND.
I don't know if there's a command to detect .devcontainer files and pick up the right settings, but it should not be hard to write one.

are there ways to use VS code plugins in google cloud shell?

I have a few quick navigation plugins such as "block travel" I use all the time. Is there a way to use these in cloud shell?
I imagine there are some restrictions, but even some simple editor plugins can be huge timesavers.
While I'm at it - alt-D to duplicate a line, or transpose lines - some of those seem to be missing and hard to use key remapping to get working, at least within the shell. In general maybe keyboard shortcuts seem to get trapped by the browser or PWA wrapper. I'm using cloudshell as a webapp on a chromebook FWIW, for various secure projects.
I have come up with a solution that covers both aspects of your question
To get Unlimited Persistent Disk:
You can use Google Cloud Storage FUSE
Google Cloud Storage FUSE lets you mount a GCS bucket as a folder to your linux instance. By doing that you get an “unlimited '' persistent disk and it is super simple to set up since gcsfuse is already installed in cloud shell.
1. Create a GCS bucket (you only need to run this once) -- replace BUCKET_NAME with any name:
gsutil mb "gs://BUCKET_NAME/"
2. Create a local directory for mounting -- replace FOLDER_NAME with the chosen directory name:
mkdir /home/[USER]/[FOLDER_NAME]
chmod 777 /home/[USER]/[FOLDER_NAME]
3. Mount the bucket onto the local filesystem (note: you need to re-run this every time Cloud Shell starts)
gcsfuse -o nonempty -file-mode=777 -dir-mode=777 --uid=1000 --debug_gcs [BUCKET_NAME] /home/[USER]/[FOLDER_NAME]
To use third party plugins in cloud shell:
You can use an environment customization script (.customization_environment) as mentioned in the public documentation. It allows you to install additional packages into your Cloud Shell environment when it starts.
For reference, below are the steps to install VS Code plug-in.
Step 1:
To install the VSCode server, run the script named visual_studio_code.sh as below, in the root directory workspace of Cloud Shell Editor.
visual_studio_code.sh file:
export VERSION=`curl -s https://api.github.com/repos/cdr/code-server/releases/latest | grep -oP '"tag_name": "\K(.*)(?=")'`
wget https://github.com/cdr/code-server/releases/download/$VERSION/code-server-3.10.2-linux-amd64.tar.gz
tar -xvzf code-server-3.10.2-linux-amd64.tar.gz
cd code-server-3.10.2-linux-amd64
Run the script using the below command in shell,
./visual_studio_code.sh
if getting permission denied error then run this following command in shell,
chmod +x visual_studio_code.sh
./visual_studio_code.sh
Step 2:
Make a customization script in the root directory workspace in Cloud Shell Editor to start VS Code Server on boot with the below commands :
.customization_environment file :
#!/bin/sh
#.customize_environmnet run in background as root, wait for your user to initialize
sleep 20
sudo -u [USER] /home/[USER]/code-server-3.10.2-linux-amd64/code-server --auth none --port 9090
Step 3:
To view Visual Studio Code server on port 9090 :
Click on Web Preview > Change Port > 9090
If getting a 404 error, remove ‘?authuser=0’ from the url.
Visual Studio Code Server will now be running on the browser!!!
Block travel navigation plugin:
To have the block travel navigation plugin in cloud shell,follow the below commands and run them in shell in root directory:
wget https://github.com/efatsi/block-travel/archive/refs/tags/v1.0.0.tar.gz
tar xzvf v1.0.0.tar.gz
ls
#You will see block-travel-1.0.0
block-travel-1.0.0/keymaps/block-travel.cson --auth none --port 9090
#You might get Permission denied if yes, then follow the next two commands else go to webport view in 9090
chmod +x block-travel-1.0.0/keymaps/block-travel.cson
block-travel-1.0.0/keymaps/block-travel.cson --auth none --port 9090
Open the webport view in 9090, you will be able to navigate through the vs code files using :
Alt+up for block-travel.jumpUp
Alt+shift+up for block-travel.selectUp
Alt+down for block-travel.jumpDown
Alt+shift+down for block-travel.selectDown
WARNING: This should not be considered a long term solution, just a stop gap until this is supported in an easier fashion.
This might not be the greatest idea but it does seem to work for the vim extension I tried in my environment. Probably best to make a request through the in product feedback to get it officially added but until then you can follow these steps.
Upload the .vsix package to your $HOME directory.
Unzip the package into the /google/devshell/editor/theia/plugins directory. This action will not persist so you'll want to add the command to the .customize_environment script actions.
e.g.
sudo unzip vscodevim.vsix -d /google/devshell/editor/theia/plugins/vscode-vim
Now for the questionable part. You'll want to install the pslist package to make life easy so you have access to the rkill command. You probably also want to add this to the .customize_environment file as well since it also will not persist.
sudo apt install pslist
Now we need to get the process id for the editor. Currently this seems to be spawned by a supervisord command, which also spawns the tmux section so we're going to grab the process id that is from the runuser command it spawns (and filter for the theia one just in case).
ps ax | grep runuser | grep "theia start"
Then we can use rkill to kill the process and all of the its children, which will cause supervisord to restart it for us and the plugin should be available.
sudo rkill PID_OF_GREP_OUTPUT
I'm not sure the best way to script the rkill command yet, since I don't know the timing of when it's up vs the .customize_environment execution, so right now I run this each time I start up a new VM.
If anything goes horribly wrong, you should be able to request a restart of the VM from the menu options and get a fresh one.
Cloud Shell offers VS Code editor experience through Theia. Did you try cloud Code editor in the cloud shell? that is exposed through "Open Editor" button on the top right, this will open cloud code editor that gives you VSCode experience. You have all the navigation keys that are available in the editor.

How to set HELM_CACHE_HOME env var (or exclude caching) when running Helm template command?

I have a specific request of running Helm template command in environment with filesystem access read-only on the regular location where Helm cache is stored (I'm executing this command inside AWS Lambda).
An error that I get is:
Error: mkdir .cache: read-only file system
Now, to overcome this problem, my idea is to:
either disable cache when running specific command
point HELM_CACHE_HOME to location which is not read-only (mounted location from EFS file system)
Unfortunately, I was unable to find a way to disable a cache and following command doesn't work (even when running it locally, without any lambda environment):
mkdir -p /tmp/helm/.cache/helm
HELM_CACHE_HOME=/tmp/helm/.cache/helm helm template elasticsearch elastic/elasticsearch --dry-run
ls -la /tmp/helm/.cache/helm
total 0
Any way to do this?
Thanks
Eventually, I've figured out that I've used incorrect environment variable.
For Helm 3, correct variable is:
XDG_CACHE_HOME
Reference: https://helm.sh/docs/faq/#xdg-base-directory-support
However, even if this works, docs say that HELM_CACHE_HOME should also work (which is not the case).

keda func deploy from a dir which contains spaces is failing

I am using Visual Code with Azure Core Tools to deploy a container to a K8S cluster which has KEDA installed. But seeing this docker error. The error is caused because the docker build is run without the double quotes.
$ func kubernetes deploy --name bollaservicebusfunc --registry sbolladockerhub --python
Running 'docker build -t sbolladockerhub/bollaservicebusfunc C:\Users\20835918\work\welcome to space'....done
Error running docker build -t sbolladockerhub/bollaservicebusfunc C:\Users\20835918\work\welcome to space.
output:
"docker build" requires exactly 1 argument.
See 'docker build --help'.
Usage: docker build [OPTIONS] PATH | URL | -
Build an image from a Dockerfile
(.venv)
20835918#CROC1LWPF1S99JJ MINGW64 ~/work/welcome to space (master)
I know there is a known bug Spaces in directory
But posting to see if there is a workaround, this is important as I have eveything in Onedrive - Comapny Name and it has spaces in it
Looking into the code for func, you could specify --image-name instead of --registry which seems to skip building the container.
You would have to build your docker container manually using the same code shown in the output and provide the value for the -t argument of the docker command for --image-name of the func command after.
Also, since this would not push your docker container as well, make sure to push it before running the func command.