(Background: I am new to Google App Engine, familiar with other cloud providers\' services)
I am looking for access/view similar to shell access to production node.
According to the SSH debugging
row in the Comparing environments table SSH access is supported for flex environment apps but not for standard environment apps.
From Connecting to the instance:
If a VM instance is in debug mode, you can connect to its host by using SSH in the console or with
gcloud
.To connect to an instance in the console:
Visit the Cloud Platform Console instances page for your project: Go to the instances page
Click SSH in the far right of the row containing the instance you want to access:
This puts the instance into debug mode, and opens an SSH session for the instance in a terminal window.
You can also select different options to start an SSH session from the drop-down list.
At this point you are in the instance host, which has several containers running in it. See Understanding common containers next for more information about these.
In the terminal window, list the containers running in the instance:
sudo docker ps
The output of the
sudo docker ps
command lists each container by row; locate the row that contains your project ID: this is the container running your code. Note the NAME of this container.Optionally, list logging information for your application by invoking:
sudo docker logs [CONTAINER-NAME]
Start a shell in the container that is running your code:
container_exec [CONTAINER-NAME] /bin/bash
When finished debugging, enter exit to exit the container, then exit again to exit the SSH session.
Disable debugging for your instance to allow it to resume normal operation.
If you are using the standard environment, the answer is no, you can't really inspect or see the code directly. You've mentioned looking at it via Stackdriver Debugger, which is one way to see a representation of it.
It sounds like if you have a reason to be looking at the code, then someone in your organization should grant you the appropriate level of access to your source code management system. I'd imagine if you're deployment practices are mature, then they'd likely branch the code to map to your deployed versions and you could inspect in detail locally.