This document provides information about a hackathon being held by Zenko and Tanker. It includes:
1) Details about the prizes for 1st, 2nd, and 3rd place which are a Parrot Mambo drone, Arduino kit, and OTHA projector.
2) Logistics for the event being held at 42 Paris from October 20-November 10 with an introduction to Zenko and Tanker on the 20th and project deployment demonstrations.
3) A list of 7 potential project ideas for teams of 2-4 people including adding MongoDB or Backblaze backend support to Zenko or using Tanker for encrypted storage.
3. Logistics
Where?
> At 42 Paris
When?
> October 20th: tech deep dive
> October 21st-November 5th: Slack support
> November 6th-10th (Scality presence 09:42->17:42)
How?
> PHP Piscine
> Scality expertise, lunch, your energy, your creativity
> Tanker expertise
4. Project Ideas
Name Description # of people
MongoDB backend Provide a MongoDB backend for S3 server/Zenko 3
Basic Vault (Accounts
only) Write an auth module for accounts (create/delete); use vault-cli 2
Encrypted PouchDB Use Tanker to store encrypted stuff in PouchDB 2-3
B2 as a backend Backblaze publishes its API : https://www.backblaze.com/b2/docs/ 3
Tanker encrypted git Write a git filter to encrypt git objects 3-4
Encrypted storage Suggested usecase : photo gallery 3
IPFS as a backend
Follow up on 42 Fremont project:
https://github.com/ssalaues/zenko-ipfs-module
3
Add your own ideas by commenting at:
Zenko hackathon ideas
Check your hackathon page (and soon, your team’s profile):
Zenko Hackathon Webpage
5. Agenda for today
Introduction to Zenko and CloudServer
Introduction to Tanker
Get started as a developer - Zenko
Get started as a developer - Tanker
Live deployment of Zenko
Live demo of Tanker
9. 9
File or object?
Why we do file:
- We know it
- Easy hierarchy
- fopen() and fclose()
- Lots of best practices
- Perf of NAS / over LAN
Why we do object:
- Billions of entries
- Storage accessed over
WAN
- For modern apps (REST)
- Listing large volumes
14. What is CloudServer?
• Open source object storage server
• Written in Node.js
• Single instance running in a Docker
container
• Uses Docker volumes for persistent
storage
• Same code as Scality’s RING S3
interface
14
21. These commands assume you have S3 cloned locally, s3cmd configured for your S3 server, AWS
cli configured for a real AWS bucket, and your locationConfig set up
-
Start CloudServer & Put Object Commands CheatSheet
24. ● When versioning is enabled on a bucket:
● CREATE NEW VERSIONS:
○ Put Object, Complete Multipart Upload and Object Copy (to a versioning-enabled bucket) will
return a version id in the ‘x-amz-version-id’ response header.
○ No special syntax necessary.
● When versioning is enabled or suspended:
● TARGETING SPECIFIC VERSIONS:
○ Include the version id in the request query for GET/HEAD Object or PUT/GET Object ACL
■ Example: `GET [bucket]/[object]?versionId=[versionId]`
○ For Object Copy or Upload Copy Part, to copy a specific version from a version-enabled
bucket, add the version id to the ‘x-amz-copy-source’ header:
■ Example value: `[sourcebucket]/[sourceobject]?versionId=[versionId]`
○ Omitting a specific version will get the result for the latest / current version.
CloudServer Highlights: object versioning
25. ● When versioning is enabled or suspended (cont.):
● NULL VERSIONS:
○ Null versions are created when putting an object before versioning is configured or when
versioning is suspended.
■ Only one null version is maintained in version history.
New null versions will overwrite previous null versions.
○ Target the null version in version-specific actions by specifying the version ID ‘null’.
● DELETING OBJECTS:
○ Regular deletion of objects will create delete markers and return ‘x-amz-delete-marker’: ‘true’
and the version ID of the delete marker in ‘x-amz-version-id’ response headers.
○ Objects with delete markers as the latest version will behave as if they have been deleted when
performing non-version specific actions.
○ Permanently remove delete markers or specific versions by specifying the version ID in the
request query. Example: `DELETE [bucket]/[object]?versionId=[versionId]`
CloudServer Highlights: object versioning
26. CloudServer Highlights: object versioning
● When versioning is enabled or suspended (cont.):
● MULTI-OBJECT DELETE:
○ Specify the specific version of an object to delete in a multi-object delete request in the XML
body. Example: http://docs.aws.amazon.com/AmazonS3/latest/API/multiobjectdeleteapi.html
● At any time:
● LISTING OBJECTS:
○ A regular listing will list the most recent versions of an object and ignore objects with delete
markers as their latest version.
○ To list all object versions and delete markers in a bucket, specify ‘versions’ in request query:
■ Example: `GET [bucket]?versions`
○ FMI about output: consult S3 Connector documentation
● GET BUCKET VERSIONING STATUS: use Get Bucket Versioning API.
27. CloudServer Highlights: UTAPI
Utapi was meant to be used programmatically. For debugging, we have included a nifty tool in CloudServer’s
docker container. It can be accessed as follows
• docker exec -it <container id> bash
• the cmd is available as node bin/list_metrics
• Sample command
node bin/list_metrics -a myAccessKey -k mySecretKey
--buckets demo -s 1490230800000 -h 127.0.0.1 -p 8100
This would list bucket level metrics for bucket demo starting from 2017-03-23T01:00:00.000Z
• Note: Since metrics are stored in 15 minute increment intervals, Utapi server requires start time to be the
start of nearest 15 minute interval. For example, valid start times would look like 09:00:00:000,
09:15:00:000, 09:30:00:000 and 09:45:00:000
End time needs to be the end of the nearest 15 minute interval. For example, valid end times would look
like 09:14:59:999, 09:29:59:999, 09:44:59:999 and 09:59:59:999
29. CloudServer Highlights: Microsoft Azure as a backend
...
"azure-test": {
"type": "azure",
"legacyAwsBehavior": false,
"details": {
"azureBlobEndpoint": "https://zenkomeetups.blob.core.windows.net/",
"bucketMatch": true,
"azureBlobSAS": "{{YOUR AZURE SAS}}",
"azureContainerName": "meetupscontainer"
}
}
...
30. Deploying Zenko
Prerequisites
- 2 machines (or more)
- a copy of the Zenko git repository
How to do it (if you’ve not read the doc…):
- bundle these machines together in a Docker Swarm cluster;
- apply a specific tag to the machine which will physically host the data and metadata
- add your credentials to the secret.txt file
- edit the docker-stack.yml file to set the number of replicas (global vs replicated)
- export your endpoint as an environment variable
- docker stack deploy -c docker-stack.yml {{stack-name}}
42. Parties can have multiple devices
Each device
has its own key pair
4
2
Multi-device
43. A resource represents
a piece of data shared by
a set of parties
Resources can be of any type:
● A document
● A record in a database
● A data structure ...
43Resource
46. ●Collection of linked blocks
●Each block contains a payload
○ (custom binary format)
●Each block has an author
●Each block is signed
●Verified by both client and server
46Trustchain
47. User ID
Tanker user IDs should match those of your existing
app or service.
Note: they are obfuscated for security reasons
60. Create a trustchain
● Send a trustchain creation request on Slack
● Someone from Tanker staff will create a Trustchain
for you
● Store the private key and the ID in a safe place
61. Creating users - the safe way
You should use a delegation token generated by your
service, so that user additions blocks are signed
properly.
62. Create your first user - the easy way
Here the delegation token is generated for you by the
SDK.
But the private key of the Trustchain is readable by the
client ...