Archive

Archive for the ‘Cloud’ Category

Logging docker to GCR registry

February 2, 2017 Leave a comment

I close my eyes, only for a moment
And the moment’s gone
All my dreams pass before my eyes, a curiosity
(Kansas – Dust in the wind)

Docker daemon can access images from multiple docker registries. Some registry can be read-only for unauthenticated users while private registries usually require authentication even for pulling images. Configuration of registries and authentication is stored in ~/.docker/config.json .

When you want to log in to docker registry, you can simply run:

docker login <registry_uri>

Command will create an entry in the ~/.docker/config.json looking like:

"registry.example.com": {
    "auth": "Tag3iekueep9raN9lae6Ahv9Maeyo1ee",
    "email": "jsosic@gmail.com"
}

But, if you want to use GCR (Google Container Registry), there is a problem – there is no password provided.

Google suggests using gcloud for accessing all of their services. To log in with your user credentials, simply run the following command:

docker login -e jsosic@gmail.com \
   -u oauth2accesstoken \
   -p "$(gcloud auth print-access-token)" \
   https://gcr.io

If you are setting a service account, then you need to use it’s private key, which Google distributes in JSON format:

docker login \
   -e service_user@compute-engine-669.iam.gserviceaccount.com \
   -u _json_key \
   -p "$(cat GCE_project-name_serviceaccount_<someid>.json)" \
   https://gcr.io

Now you can pull existing images from your private registry:

docker pull gcr.io/compute-engine-669/redis:latest

Isn’t it cool?

Categories: Cloud, Docker, GCE, Linux Tags: , ,

Rescuing GCE compute instance

September 17, 2016 Leave a comment

I’m digging deep inside my soul
To bring myself out of this God-damned hole
I rid the demons from my heart
And found the truth was with me from the start
(Halford – Resurrection)

If you’re still managing servers as pets and not as cattle – inevitable happens: filesystem breaks, sshd gets killed, wrong iptables settings get applied, wrong mount option halts boot process – and you’re in deep. Your important server is inaccessible.
If your server is running on in-house managed VmWare or XenServer, .NET console will help you rescue it. If it’s running on bare metal, you can rely on iDRAC or something similar. But, if you’re running in cloud – you’re pretty much screwed.

If you’re running GCE, there are couple of options at your disposal at the time of dismay. First, there is a beta Virtual Serial Port option that you can connect to and see where the hell did your instance halt and what messages are printed.

To enable Virtual Serial Port, you need to have gcloud (command line tool) installed and authenticated to your project. So, first thing is to list available instances:

% gcloud compute instances list
NAME   ZONE        MACHINE_TYPE   INTERNAL_IP  EXTERNAL_IP      STATUS
test   us-east1-b  g1-small       10.240.0.5   104.155.112.80   RUNNING

Now, to be able to connect to Virtual Serial Console, you need to set up ssh keys properly. Username and keys from your project metadata can be obtained by running:

% ssh-keygen ~/.ssh/google_compute_engine
% gcloud compute project-info add-metadata \
   --metadata-from-file sshKeys=google_compute_engine.pub

If you already have a key, you will need to set up both ~/.ssh/google_compute_engine and ~/.ssh/google_compute_engine.pub to match the key from the project.

After the keys are set, you can finally connect:

% gcloud beta compute connect-to-serial-port gceuser@test

You should probably get a standard TTY login prompt.

If an attempt to fix the problem through GCE Virtual Serial Console didn’t succeed, but you think boot disk can be saved by attaching it to other instance, you will need to:

  • disable “auto delete boot disk”
  • destroy instance 😦
  • attach boot disk as additional disk to another VM
  • mount it, fix whatever is broken, umount it
  • detach disk from instance
  • create new instance, and choose this disk as boot disk

Using gcloud, it would look something like this

% gcloud compute instances \
  set-disk-auto-delete test --no-auto-delete --device-name test
% gcloud compute instances delete test
% gcloud compute instance

You should probably get a standard TTY logi

%d bloggers like this: