How to launch an Instance from backup per Rest api?
How to point to the image source, as it is only visible in name space or by zfs force mounting /var/snap/lxd/common/lxd/storage-pools/pl/custom/default_backups ?
Same goes for backup downloads.
Supposed I want force a php download. Fetching the streams from curl:
/1.0/storage-pools/pool/volumes/type/volume/backups/name/export
Redirecting to php download quite a challenge!
Or export it first to a local location, then from that image proceed further?
The invisibility of images backups container root … in my case produces a lot more work and permanent extra api calls to find out the size and other sort of information which previously much easier done by php and shell commands.
You said your using php are you using a client library?
Yes, I do.
Own code.
mix of C, Shell, PHP, javascript.
Mine by far not as comprehensive and advanced as your solution!
Hope, I am allowed to link to your lxdmosaic:
LXDMOSAIC
I implemented a poor man’s solution, as compact size and fewer modules/libraries dependency was a concern.
It runs on 10MB Alpine/Nginx Instance, of course Postgresql (external) adds up a little bit to that.
The application size by itself, PHP, bash, C binaries totaling 10 MB).
I was looking at php-lxd which I forked from someone else & maintain, its the underlying PHP lib that LXDMosaic uses interact with LXD instances.
To launch an instance from a backup, you need to POST an exported backup to /1.0/instances/name.
From the LXD docs;
Input (using a backup):
Raw compressed tarball as provided by a backup export (/1.0/instances//backups//export). The X-LXD-name header can be set to override the target instance name. The X-LXD-pool header can be set to override the target storage pool.
Thanks!
Very helpful!
I must have missed that in docs, as it was the one without any data structure!
So, it is a two steps action?
data is:
$data = curl get “/1.0/instances/name/backups/name/export”
The provided data to
curl -X 'POST -d $data “/1.0/instances/name”
Right?
I know, there has been a lot of considerations of design and security which led to user spaces.
But as far as I am concerned, my life was easier prior to that!
This issue is about a simple tar file, which normally could be seen, played with, moved around, downloaded, deleted …
Now I really need to utilize some rocket science to beg lxd to give a second of privacy with my obfuscated, hidden and unmounted file.
Sounds about right!
You can surely just encrypt the tar file yourself?
You are right.
I had started replacing some direct system interactions through rest api.
Though, it still is an option to zfs snapshot -> send -> compressor -> tar.compressed.backup and get it back by zfs receive.