Painéis Steampipe e benchmarks para seus dados

No Steampipe desagregado, mostramos como seus plug-ins, que originalmente funcionavam apenas com o wrapper de dados externo carregado no Postgres incluído com baterias do Steampipe, agora também estão disponíveis como distribuições independentes que você pode carregar em suas próprias instâncias do Postgres ou SQLite. Agora o próprio Steampipe está desagregado: seu servidor de painel e executor de benchmark migraram para um novo projeto de código aberto, Powerpipe.

Quando você inicia o Powerpipe, o padrão é uma instância local do Steampipe para que os painéis e benchmarks existentes funcionem como sempre. Os mods que os orientam obtêm seus dados dos mesmos plug-ins, usando as mesmas consultas SQL. Mas você pode usar o Powerpipe --database argumento para especificar uma string de conexão Postgres, SQLite, DuckDB ou MySQL.

Por que desmembrar o Steampipe desta forma? A filosofia Unix afirma que uma ferramenta de software deve fazer uma coisa bem e combinar-se prontamente com outras ferramentas que sigam o mesmo princípio. O Steampipe começou assim, mas à medida que as camadas do painel e do benchmark apareceram, ficou claro que a refatoração era necessária. Para engenheiros Devops que usam a ferramenta para visualizar e avaliar a infraestrutura em nuvem, faz sentido desacoplar essas camadas em componentes com interfaces bem definidas. Mas o Powerpipe não é só para eles. Entre o conjunto de novos mods lançados com o Powerpipe, há um que visualiza dados biomédicos do RNACentral por meio de um endpoint público do Postgres. Para visualizar esses painéis, você instala o mod e inicia o Powerpipe assim:

powerpipe server --database postgres://reader:[email protected]:5432/pfmegrnargs

Os painéis agora podem ser navegados em http://localhost:9033.

É claro que você pode conectar qualquer cliente Postgres a esse endpoint. O que o Powerpipe traz para a festa é uma abordagem como código para visualizar e validar dados. Os widgets que orientam os painéis e os benchmarks são escritos em uma linguagem declarativa, HCL, que complementa as consultas SQL declarativas que preenchem esses widgets com dados. Todo o seu código HCL e SQL reside em repositórios, sob controle de versão, abertos ao mesmo tipo de colaboração que você espera e aproveita para todos os outros artefatos de código.

Trabalhar com esse código também é uma experiência amigável ao desenvolvedor de outra maneira. O Powerpipe monitora seus arquivos e reage instantaneamente quando você faz alterações na HCL que configura os widgets do painel ou no SQL que os preenche.

Gráficos de relacionamento baseados em SQL

O conjunto de componentes do painel inclui tudo o que você espera, incluindo tabelas, gráficos, cartões de informações e widgets de entrada. Também inclui algumas coisas que você talvez não espere, principalmente os nós e arestas que formam gráficos de relacionamento. Aqui está um exemplo que usa um widget de seleção para escolher um autor do InfoWorld e, em seguida, constrói um gráfico que relaciona o autor escolhido aos artigos escritos e às (talvez múltiplas) categorias associadas a cada artigo.

Veja como os nós e arestas são definidos. Dois dos nós consultam categorias e autores, e o terceiro usa o plugin RSS para consultar o feed RSS do autor selecionado. Então duas arestas conectam os nós. Um relaciona os links dos artigos aos autores, o outro relaciona os mesmos links às categorias. É tudo apenas SQL, aproveitado de uma forma não convencional.

-- enumerate categories
node {
  category = category.category
  sql = <<EOQ
    select
      category as id,
      category as title
    from
      infoworld_categories()
  EOQ
}

-- enumerate authors
node {
  category = category.author
  args = (self.input.authors.value)
  sql = <<EOQ
    select
      author as id,
      author as title
    from
      infoworld_authors()
    where 
      author = $1
  EOQ
}

-- list articles by author
node {
  args = (self.input.authors.value)
  category = category.post
  sql = <<EOQ
  with feed_links as materialized (
    select
      author,
      'https://www.infoworld.com/author/' || author || '/index.rss' as feed_link
    from infoworld_authors()
  )
  select
    link as id,
    title as title,
    author,
    jsonb_build_object(
      'link', link,
      'author', author,
      'published', published
    ) as properties
  from
    rss_item r
  join
    feed_links f
  using (feed_link)
  where author = $1
  order by 
    published desc
  EOQ
}

-- relate articles to authors
edge {
  args = (self.input.authors.value)
  sql = <<EOQ
    with feed_links as materialized (
      select
        author,
        'https://www.infoworld.com/author/' || author || '/index.rss' as feed_link
      from infoworld_authors()
    )
    select
      link as to_id,
      author as from_id
    from
      rss_item r
    join
      feed_links f
    using (feed_link)
    where
      author = $1
  EOQ
}

-- relate articles to categories
edge {
  sql = <<EOQ
    select
      link as to_id,
      category as from_id
    from
      infoworld_category_urls()
  EOQ
}

Os usos mais típicos desses gráficos de relacionamento ajudam os engenheiros de devops a entender como os elementos de suas infraestruturas de nuvem se encaixam, como por exemplo neste gráfico que mostra como os componentes de uma implantação do Kubernetes – implantações, conjuntos de réplicas, pods, contêineres, servidores e nós – relacionar-se um com o outro. Cada entidade no gráfico tem um hiperlink para outro gráfico que detalha a entidade e detalha a infraestrutura circundante.

Essas visualizações, que também estão disponíveis para AWS, Azure e GCP, são uma excelente maneira de explorar e compreender suas arquiteturas de nuvem. E as consultas que você escreve para fazer isso são reutilizáveis. Você pode transferir os mesmos dados para gráficos e tabelas do painel.

Benchmarks e controles baseados em SQL

Powerpipe também é o mecanismo que alimenta conjuntos de benchmarks de conformidade, também para AWS, Azure, GCP, Kubernetes e outros. Aqui está um benchmark que valida os URLs de imagem incorporados no extensions campo de feeds RSS do InfoWorld.

E aqui está como é definido. O benchmark inclui um controle que executa uma consulta em várias etapas para selecionar URLs de feed para autores, detalhar cada item meios de comunicação tag e verifique o código de resposta HTTP para cada URL.

control "image_urls" {
  title = "Image URLS"
  sql = <<EOT
  with authors as (
    select 
    author,
    'https://www.infoworld.com/author/' || author || '/index.rss' as feed_link
    from 
      infoworld_authors()
    limit 1
  ),
  image_urls as materialized (
    select
      a.author,
      r.extensions -> 'media' -> 'content' -> 0 -> 'attrs' ->> 'url' as url
    from 
      authors a
    join
      rss_item r
    using (feed_link)
  ),
  response_codes as (
    select
      i.author,
      n.url,
      n.response_status_code
    from
      net_http_request n
    join
      image_urls i
    using (url)
  )
  select
    url as resource,
    case when response_status_code = 200 then 'ok'
    else 'alarm'
   end as status,
    case when response_status_code = 200 then 'image found'
    else 'image not found'
   end as reason,
   substring(url from 1 for 150), 
   author
  from response_codes
  EOT
}

benchmark "feeds" {
  title = "Check InfoWorld feeds"
  children = (
    control.image_urls
  )
}

Pontos notáveis ​​aqui:

• O feed_link coluna retornada do primeiro CTE (expressão de tabela comum) se junta à sua contraparte no plugin RSS para buscar o feed de cada autor.
• Como o back-end é o Steampipe, que é baseado no Postgres, os operadores JSONB do Postgres estão disponíveis para detalhar o media tag e extraia o URL.
• Cada url em seguida, junta-se à coluna correspondente do plugin Net – um cliente HTTP encapsulado como uma tabela de banco de dados! – para verificar o código de resposta.

Um controle é apenas uma consulta SQL que retorna as colunas necessárias status, reasone resource. Você pode pensar em um controle como um teste de unidade para dados, com o Powerpipe como testrunner.

Esses controles normalmente oferecem suporte a conjuntos de conformidade padrão: CIS, FedRamp, GDPR, HIPAA, NIST, PCI, SOC 2 e muito mais. Mods como AWS Compliance oferecem suporte amplo e profundo para eles, com base na cobertura de API igualmente ampla e profunda fornecida por plug-ins Steampipe como o da AWS.

Mas você pode criar mods de benchmark para validar qualquer tipo de dados, onde quer que estejam: em tabelas efêmeras preenchidas por serviços em nuvem por meio de plug-ins ou em seus próprios bancos de dados como tabelas nativas.

Painéis e benchmarks como código

Esteja você visualizando dados com tabelas, tabelas e gráficos interativos ou validando dados usando controles, o modelo é o mesmo. Você usa consultas SQL para adquirir os dados e widgets HCL para exibi-los, com edição ao vivo em ambos os casos. O código reside em pacotes chamados mods que você pode instalar, criar e remixar.

Assim como o produto Steampipe do qual foi desacoplado, o Powerpipe é um binário único que você pode executar localmente, ou em uma VM na nuvem, ou em um pipeline de CI/CD. E como o Steampipe, está disponível em formato hospedado no Turbot Pipes, onde você pode colaborar com sua equipe e compartilhar instantâneos de painéis e benchmarks.

Os conjuntos existentes de painéis e benchmarks Powerpipe concentram-se no que o pessoal do DevOps mais precisa: uma linguagem de consulta padrão, com acesso ao vivo a APIs em nuvem, incorporada em wrappers HCL que residem em repositórios junto com o restante do seu código gerenciado. Esse é o ponto ideal, mas com a desagregação do Steampipe agora você pode usar as mesmas tecnologias de forma mais ampla.