Skip to content
This repository has been archived by the owner on Apr 5, 2022. It is now read-only.
/ infraql Public archive

Query and Provision Cloud Infrastructure using an extensible SQL based grammar

License

Notifications You must be signed in to change notification settings

infraql/infraql

Repository files navigation

Platforms Go License Lines
StackQL

Deploy, Manage and Query Cloud Infrastructure using SQL

This repository has been archived. The active project is now located at StackQL

[Documentation] [Developer Guide]

Cloud infrastructure coding using SQL

InfraQL allows you to create, modify and query the state of services and resources across all three major public cloud providers (Google, AWS and Azure) using a common, widely known DSL...SQL.


Its as easy as...

use google; SELECT * FROM compute.instance WHERE zone = 'australia-southeast1-b' AND project = 'my-project' ;

Design

infraql generalizes the idea of infrastructure / computing reources into a provider, service, resource heirarchy that can be queried with SQL semantics, plus some imperative operations which are not canonical SQL. Potentially any infrastructure: computing, orchestration, storage, SAAS, PAAS offerings etc can be managed with infraql, athough the primary driver is cloud infrastructure management. Multi-provider queries are to be a first class citizen in infraql.

Considering query execution in a bottom-up manner from backend execution to frontend source code processing, the strategic design for infraql is:

  • Backend Execution of queries through Primitive interfaces that encapsulate access and mutation operations against arbitrary APIs. Primitives may act on any particular API, eg: http, SDK, IPC, specific wire protocol. Potentially variegated (eg: part http API, part SDK).
  • A Plan object includes a DAG of Primitives. Plans may be optimized and cached a la vitess. Logically, the Plan, once initialized, is matured in the following sequential phases:
    1. Intermediate Code Generation; for now no formal language is defined. Simply objects and function pointers of infraql, encapsulated in Primitives.
    2. Code Optimization; parallelization of independent operations, removal of redundant operations.
    3. Code Generation; final calls against whatever backend, eg http API.
  • Semantic Analysis of queries is a phase that accepts an AST as input and:
    • creates a symbol table.
    • analyzes provider heirarchies and API(s) required to complete the query. Typically these would be sourced by downloading and cacheing provider discovery documents.
    • performs type checking, scope (label) analysis.
    • creates a Planbuilder object and decorates it during analysis.
    • may generate some primitives.
    • generates, at the very least, a Plan stub.
  • Lexical and Syntax analysis; using the machinery from Vitess, which is a lex / yacc style grammar, processed with golang libraries to emulate lex and yacc. The sqlparser module, originally from vitess contains the implementation. The output is an AST.

The semantic analysis and latter phases are sensitive to the type and structure of provider backends.

infraql supports specific API versions for providers, API upgrades may require infraql reversioning.


Providers

Starting off with Google. Other providers to follow.


Build

With cmake:

cd build
cmake ..
cmake --build .

Executable build/infraql will be created.

Run

./build/infraql --help

Examples

./infraql exec "show extended services from google where title = 'Service Directory API';"

More examples in /examples.md.


Developers

/developer_guide.md.

Testing

/test/README.md.

Acknowledgements

Forks of the following support our work:

We gratefully acknowledge these pieces of work.

License

See /LICENSE