That's one way to get it done.
You can also support multiple regions by copying the uploaded AMI using aws ec2 copy-image if you like.
I left comments suggesting improvement by using awss own --query flag to extract the output instead of filtering through jq (thus reducing the need for yet another tool).
I gave instructions in the comment as much as I can without testing the specific command.

Hi Julian,

In T100#4801, @silverbp wrote:

I don't know enough to be able to do this in GCE without some help, not sure where to start. I was using the AWS packer image as an example but got stuck. If I have something to go off of, I can use that and work through it and/or ask questions as needed.

Just posting here in case someone can help me out -

In T100#4598, @mtz4718 wrote:

Is this en-devour dead? I really want to help but I wonder I'd be much use. If there's any dumb testing or boring tasks let me know.

I'm not building the VyOS from source but extract it from the nightly .iso file.
This works great for me with VyOS 1.1.7.
Debian Jessie doesn't have the kernel 3.18 which is required for OverlayFS.

I'm building the VyOS disk image under another OS (latest test using Ubuntu 16.04 LTS) and was testing the extra configuration script under chroot. Your response would explain that the missing unionfs packages on the host OS could explain the error I get. I'll install them and try again.

I managed to get past the OverlayFS issue by adding:

Question from @silverbp :>>! In T100#4449, @silverbp wrote:

@syncer yes please split it off. Sorry for taking over the ticket.

I got the VyOS 1.2 AMI built by Packer but it doesn't get the ssh key pulled from the metadata and stored in the configuration. With lots of manual testing I got to a stage where "/bin/cli-shell-api setupSession" fails with a core dump.

I've updated https://github.com/amosshapira/thermal to let you specify VPC ID and subnet ID required to run Packer in AWS.

How do you get the code for 1.2 into your image? I use the ISO of 1.1.7 and started work for 1.2.0 and made some progress but stopped when I hit too many problems and realised that 1.2 isn't stable (that was a few months ago).

I've just verified that the AMI gets built and runs correctly after making sure that the VPC ID and Subnet ID are set correctly in packer.json. I'll update my code when I get home. The issue to track this is https://github.com/amosshapira/thermal/issues/5

ami-72343365 is Ubuntu official public trusty AMI in us-east-1, name "ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-20161205" owner id "099720109477"

@silverbp have you considered using Packer? I got Packer building AMI's of VyOS on AWS here: https://github.com/amosshapira/thermal/tree/master/vyos-image, perhaps you can use it as a basis for a GCE image. Let me know if you need help with understanding the code there (it uses a trick to work around Packer's lack of support for creating the final image from a "side-mounted" volume by switching volumes and rebooting).

This is different but might be a little related - FoxPass publishes a one-line tweak to VyOS 1.0 to let them support two-factor authentication for IPSec VPN at https://foxpass.readme.io/docs/vyatta-vyos-ubiquity-vpn-clients
It would be nice to have this change possible via an option.

I'm not sure how much this will help, but I have a branch on a fork of vyos-build to build AMI's from ISO files: https://github.com/amosshapira/vyos-build/tree/make-ami

I think the usual short name for Google Cloud is "GCE" (Google Cloud Engine).

I have a python script which will read a VPN Connection configuration from a Virtual Gateway and emit VyOS commands to configure it as a client to that VPN connection.

The 169.254/16 is a special link-local subnet which by definition can't be routed outside the immediate link (as far as I follow it). See https://tools.ietf.org/html/rfc3927 for authoritative definition.

Thanks for the update.
Where can I get 1.2 to help testing?

Thanks. I'll try to find how to follow this advice.

Thanks for your research and findings.

@jeffbearer how about policy routing and telling Linux that traffic should only use local 169.254/16 source address if its destination is also on 169.254?

That (using iptables to munge the DNS traffic) sounds like a great work-around. I like it because if it works then I can set it as part of the VyOS standard configuration.

I have BGP tunnel up over the IPSec tunnel between the VyOS and the AWS Virtual GW.

I'm not an expert but my understanding of the definition of 169.254/16 is that it's a "link local" address and shouldn't be used for "real traffic", e.g. AWS uses it to pass EC2 metadata through 169.254.169.254, or see https://tools.ietf.org/html/rfc3927 for how this network is defined.
So I think that the solution should more in the direction of somehow telling VyOS to prefer the local interface address over the 169.254 address.

Thanks but I can't use GRE or OVPN since the other side is AWS virtual gateway (more specifically, I use it as a Virtual CloudHub connecting offices and multiple VPC's).