Entendendo network drivers no Docker - Related to sheet, kubectl, drivers, no, cheatsheet

AWS Redshift Cheat Sheet

AWS Redshift Cheat Sheet for AWS Certified Data Engineer - Associate (DEA-C01).

Amazon Redshift is a fully managed, petabyte-scale data warehouse service in the cloud. It's designed for high performance analytics and business intelligence workloads.

Clusters: Collection of computing resources called nodes Nodes: Individual compute units that process queries Leader Node: Manages client connections and query planning Compute Nodes: Execute queries and store data Slices: Partitions of compute nodes where data is stored Databases: Collections of tables Workload Management (WLM): Controls query prioritization and resource allocation Redshift Spectrum: Query data directly from S3 without loading Concurrency Scaling: Automatically adds cluster capacity to handle increased demand.

Amazon Redshift ├── Cluster Architecture │ ├── Leader Node │ │ ├── Query Planning │ │ ├── Result Aggregation │ │ └── Client Connection Management │ └── Compute Nodes │ ├── Data Storage │ ├── Query Execution │ └── Slices (Data Partitions) ├── Data Storage │ ├── Columnar Storage │ ├── Zone Maps │ ├── Data Compression │ └── Data Distribution │ ├── Even Distribution │ ├── Key Distribution │ └── All Distribution ├── Query Processing │ ├── MPP Architecture │ ├── Query Optimization │ └── Result Caching └── Management aspects ├── Workload Management (WLM) ├── Concurrency Scaling ├── AQUA (Advanced Query Accelerator) ├── Redshift Spectrum └── Automatic Table Optimization Enter fullscreen mode Exit fullscreen mode.

Node Type vCPU Memory Storage I/O Use Case RA3 Nodes ra3.16xlarge 48 384 GB Managed 4x Large data warehouses ra3.4xlarge 12 96 GB Managed 2x Medium data warehouses [website] 4 32 GB Managed [website] Small data warehouses DC2 Nodes dc2.8xlarge 32 244 GB [website] TB SSD High Compute-intensive workloads [website] 2 15 GB 160 GB SSD Moderate Small data warehouses Serverless Serverless Auto-scaling Auto-scaling Managed Varies Unpredictable workloads.

Distribution Style Description Best For Performance Impact AUTO Redshift assigns optimal distribution General use Good for most cases EVEN Rows distributed evenly across slices Tables without clear join key Balanced storage, potential data movement during joins KEY Rows with same values in distribution column on same slice Join tables on distribution key Minimizes data movement during joins ALL Full copy of table on every node Small dimension tables Fast joins but storage overhead.

Sort Key Type Description Best For Performance Impact Compound Sort by column order (like a phone book) Range-restricted scans on sort columns Excellent for queries filtering on prefix of sort key Interleaved Equal weight to each sort column Queries with predicates on different columns advanced for varied query patterns Automatic Redshift chooses optimal sort key General use Good for most cases.

Encoding Best For Compression Ratio Performance Impact RAW Binary data, already compressed None Baseline AZ64 Numeric data Good Fast computation BYTEDICT Limited distinct values Very high Fast for small domains DELTA Incremental numeric data High Good for dates, timestamps LZO Very large text columns Moderate Good general purpose ZSTD Varied data types High Good general purpose, improved than LZO RUNLENGTH Repeated values Very high Excellent for low-cardinality columns TEXT255/TEXT32K Variable-length strings High Good for text.

crucial Redshift Limits and Performance Factors.

Maximum of 500 concurrent connections per cluster Default query timeout is 1 hour (configurable) Maximum of 50 concurrent queries by default Maximum of 100 databases per cluster Maximum of 9,900 schemas per database Maximum of 200,000 tables per cluster (including temporary tables) Maximum row size is 4 MB Maximum column name length is 127 bytes Maximum 1,600 columns per table Maximum identifier length is 127 bytes Maximum SQL statement size is 16 MB.

Use COPY command for bulk data loading (8-10x faster than INSERT) Choose appropriate distribution keys to minimize data movement Use sort keys for columns frequently used in WHERE clauses Vacuum regularly to reclaim space and resort data Analyze tables to modification statistics for the query planner Use appropriate compression encodings for columns Avoid SELECT * and retrieve only needed columns Use UNLOAD to export large result sets to S3 Implement proper partitioning when using Redshift Spectrum Use materialized views for common, complex queries.

Use COPY command from S3, not INSERT statements Split large files into multiple files (1-128 MB each) Use gzip compression for load files Load data in parallel using multiple files Use a manifest file to ensure all files are loaded Use STATUPDATE ON to enhancement statistics after loading Use COMPUPDATE ON for automatic compression analysis Temporarily disable automatic compression for very large loads Use a single COPY transaction for related tables Example COPY command:

COPY customer FROM 's3://mybucket/customer/data/' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' REGION 'us-west-2' GZIP COMPUPDATE ON ; Enter fullscreen mode Exit fullscreen mode.

Automatic WLM: Redshift manages query queues and memory allocation Manual WLM: Define up to 8 queues with custom settings Short Query Acceleration (SQA): Prioritizes short-running queries Concurrency scaling: Automatically adds transient clusters for read queries Query monitoring rules: Define metrics-based actions for long-running queries Query priority: Assign importance levels to different workloads User groups: Assign customers to specific WLM queues Memory allocation: Control percentage of memory allocated to each queue Concurrency level: Set maximum concurrent queries per queue Timeout: Set maximum execution time per queue.

Query data directly in S3 without loading into Redshift Supports various file formats: Parquet, ORC, JSON, CSV, Avro Uses external tables defined in AWS Glue Data Catalog Scales automatically to thousands of instances Supports complex data types and nested data Partition pruning improves performance dramatically Charged separately from Redshift cluster usage Example external table creation:

CREATE EXTERNAL TABLE spectrum . sales ( salesid INTEGER , listid INTEGER , sellerid INTEGER , buyerid INTEGER , eventid INTEGER , dateid INTEGER , qtysold INTEGER , pricepaid DECIMAL ( 8 , 2 ), commission DECIMAL ( 8 , 2 ) ) PARTITIONED BY ( saledate DATE ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ' \t ' STORED AS TEXTFILE LOCATION 's3://mybucket/spectrum/sales/' ; Enter fullscreen mode Exit fullscreen mode.

VPC networking with security groups IAM integration for authentication and authorization Column-level access control Row-level security policies Dynamic data masking AWS KMS integration for encryption at rest SSL for encryption in transit CloudTrail integration for audit logging Multi-factor authentication support Integration with AWS Lake Formation for fine-grained access control.

Automated snapshots (1-35 day retention) Manual snapshots (retained until deleted) Cross-region snapshot copy for disaster recovery Point-in-time recovery (up to 5-minute increments) Snapshot sharing across AWS accounts Automated snapshot schedule (every 8 hours by default) Snapshot restore to new cluster Incremental snapshots to minimize storage costs Snapshot storage in S3 (separate from cluster storage) Continuous backup to RA3 clusters.

No cluster management required Automatic scaling of compute resources Pay only for what you use (RPU-seconds) Automatic pause and resume Seamless transition from provisioned clusters Same SQL interface as provisioned Redshift Integrated with Redshift Spectrum Base capacity specified in Redshift Processing Units (RPUs) Maximum capacity limits to control costs Ideal for unpredictable or intermittent workloads.

S3: Data loading, unloading, and Spectrum AWS Glue: Data catalog for Spectrum AWS DMS: Data migration to Redshift Kinesis Data Firehose: Streaming data ingestion AWS Lambda: Automated ETL and maintenance QuickSight: Business intelligence and visualization Lake Formation: Fine-grained access control CloudWatch: Monitoring and alerting CloudTrail: Audit logging AWS Secrets Manager: Credential management.

Feature Redshift PostgreSQL Apache Hive Presto Architecture MPP, columnar SMP, row-based MPP on Hadoop MPP query engine Scale Petabytes Terabytes Petabytes Petabytes Performance Very high Moderate Low to moderate High for queries Management Fully managed Self-managed Self-managed Self-managed Cost model Pay for capacity Infrastructure cost Infrastructure cost Infrastructure cost SQL compliance PostgreSQL [website] compatible Full PostgreSQL HiveQL (limited) ANSI SQL Concurrency Limited (50+) High Limited Moderate Use case Data warehousing OLTP, small OLAP Batch analytics Interactive queries.

critical CloudWatch Metrics for Monitoring.

Metric Description Threshold Action CPUUtilization Percentage of CPU used >80% sustained Consider scaling or query optimization PercentageDiskSpaceUsed Storage utilization >80% Resize cluster or clean up data DatabaseConnections Active connections >80% of max Increase connection limit or optimize connection pooling QueriesCompletedPerSecond Query throughput Baseline dependent Monitor for unexpected changes QueryDuration Time to execute queries Baseline dependent Optimize slow queries WLMQueueLength Queries waiting in queue >5 consistently Adjust WLM or scale cluster WLMQueueWaitTime Time queries wait in queue >5 seconds Adjust WLM or scale cluster ReadIOPS Read operations per second Baseline dependent Monitor for spikes or drops WriteIOPS Write operations per second Baseline dependent Monitor for spikes or drops ReadLatency Time for disk read operations >20ms Investigate storage issues WriteLatency Time for disk write operations >20ms Investigate storage issues ConcurrencyScalingActiveClusters Number of scaling clusters Cost dependent Monitor for unexpected scaling.

Data Ingestion and Pipeline Replayability.

Use COPY command with manifest files to track loaded files Implement idempotent data loading with IDENTITY columns or natural keys Use staging tables and transactions for atomic loads Implement error handling with MAXERROR parameter in COPY Store raw data in S3 for reprocessing if needed Use Kinesis Data Firehose for streaming data ingestion Implement data validation before and after loading Use AWS Glue for ETL job orchestration Implement checkpointing in data pipelines for resumability Use AWS Step Functions for complex pipeline orchestration.

COPY command throughput: Up to several GB/s depending on cluster size Bulk loading is significantly faster than row-by-row inserts Query latency varies from milliseconds to hours depending on complexity Concurrency scaling adds read capacity within seconds Elastic resize completes within minutes Classic resize can take hours depending on data volume Vacuum operation speed depends on unsorted data percentage Redshift Spectrum queries have higher latency than local queries WLM queue wait time impacts overall query latency Result caching provides sub-second response for repeated queries.

Implementing Throttling and Overcoming Rate Limits.

Use connection pooling to manage database connections Implement exponential backoff for API calls Use WLM to prioritize critical queries Implement client-side query queuing for high-concurrency applications Use short query acceleration for time-sensitive small queries Batch small inserts into larger COPY operations Use concurrency scaling for read-heavy workloads Implement retry logic for throttled operations Monitor and alert on queue wait times Use reserved capacity for predictable workloads.

Materialized views for precomputed query results Automatic table optimization for sort and distribution keys Automatic vacuum delete for maintaining performance Automatic analyze for statistics maintenance Query monitoring rules for workload management Federated queries to access data in other databases Data sharing across Redshift clusters Machine learning integration with Amazon SageMaker Spatial data support for geospatial analytics HyperLogLog functions for cardinality estimation Time series functions for time-based analysis Window functions for advanced analytics AQUA (Advanced Query Accelerator) for RA3 nodes Cross-database queries within a cluster Semi-structured data support (SUPER data type) JSON and PartiQL support for flexible data models Stored procedures for complex logic User-defined functions (UDFs) for custom operations.

Key Takeaways Selling yourself and your stakeholders on doing architectural experiments is hard, despite the significant benefits of this approach; yo......

Animations can elevate the user experience in mobile apps, making them more engaging and intuitive. One of the best libraries for adding smooth, light......

The energy sector is evolving rapidly, with decentralized energy systems and renewable energy data taking center stage. One of the most exciting de......

Kubectl CheatSheet 2025

Kubectl is the command-line interface for interacting with Kubernetes clusters. It allows you to deploy applications, inspect and manage cluster resources, and view logs. This cheatsheet provides a comprehensive reference of commonly used kubectl commands, organized by operation type.

Whether you're new to Kubernetes or an experienced administrator, this guide will help you quickly find the right command for your task. Commands are presented with their descriptions and practical examples to make your Kubernetes workflow more efficient.

Command Description Example kubectl cluster-info Display cluster info kubectl cluster-info kubectl version Show kubectl and cluster version kubectl version kubectl config view Show kubeconfig settings kubectl config view kubectl config current-context Display current context kubectl config current-context kubectl config use-context Switch to another context kubectl config use-context minikube kubectl config set-context Set a context parameter kubectl config set-context --current --namespace=myapp kubectl api-resources List supported API resources kubectl api-resources.

Command Description Example kubectl get namespaces List all namespaces kubectl get ns kubectl create namespace Create a namespace kubectl create ns app-dev kubectl delete namespace Delete a namespace kubectl delete ns app-dev kubectl config set-context --current --namespace= Set default namespace kubectl config set-context --current --namespace=app-dev.

Command Description Example kubectl get pods List all pods in current namespace kubectl get pods kubectl get pods --all-namespaces List pods in all namespaces kubectl get pods -A kubectl get pods -o wide List pods with more details kubectl get pods -o wide kubectl describe pod Show detailed pod information kubectl describe pod nginx-pod kubectl run --image= Create and run a pod kubectl run nginx --image=nginx kubectl delete pod Delete a pod kubectl delete pod nginx-pod kubectl logs Get pod logs kubectl logs nginx-pod kubectl logs -f Stream pod logs kubectl logs -f nginx-pod kubectl logs -c Get container logs from multi-container pod kubectl logs webapp -c auth-service kubectl exec -it -- Execute command in pod kubectl exec -it nginx-pod -- /bin/bash kubectl port-forward : Forward pod port to local kubectl port-forward nginx-pod 8080:80.

Command Description Example kubectl get deployments List all deployments kubectl get deploy kubectl describe deployment Show deployment details kubectl describe deploy nginx-deploy kubectl create deployment --image= Create a deployment kubectl create deploy nginx --image=nginx kubectl scale deployment --replicas= Scale a deployment kubectl scale deploy nginx --replicas=5 kubectl rollout status deployment Check rollout status kubectl rollout status deploy nginx kubectl rollout history deployment View rollout history kubectl rollout history deploy nginx kubectl rollout undo deployment Rollback deployment kubectl rollout undo deploy nginx kubectl rollout restart deployment Restart deployment (for image refresh) kubectl rollout restart deploy nginx kubectl set image deployment/ = upgrade container image kubectl set image deployment/nginx nginx=nginx:latest kubectl delete deployment Delete a deployment kubectl delete deploy nginx.

Command Description Example kubectl get services List all services kubectl get svc kubectl describe service Show service details kubectl describe svc nginx-service kubectl expose deployment --port= --type= Create a service for deployment kubectl expose deploy nginx --port=80 --type=LoadBalancer kubectl delete service Delete a service kubectl delete svc nginx-service.

Command Description Example kubectl get configmaps List all configmaps kubectl get cm kubectl get secrets List all secrets kubectl get secrets kubectl create configmap --from-file= Create configmap from file kubectl create cm app-config --from-file=config.properties kubectl create configmap --from-literal== Create configmap from literal kubectl create cm app-config [website][website] kubectl create secret generic --from-literal== Create secret from literal kubectl create secret generic db-creds --from-literal=password=s3cr3t kubectl describe configmap Show configmap details kubectl describe cm app-config kubectl describe secret Show secret details kubectl describe secret db-creds.

Command Description Example kubectl get persistentvolumes List persistent volumes kubectl get pv kubectl get persistentvolumeclaims List persistent volume hints at kubectl get pvc kubectl describe persistentvolumeclaim Show PVC details kubectl describe pvc mysql-pvc kubectl delete persistentvolumeclaim Delete a PVC kubectl delete pvc mysql-pvc.

Command Description Example kubectl get nodes List all nodes kubectl get nodes kubectl describe node Show node details kubectl describe node worker-1 kubectl cordon Mark node as unschedulable kubectl cordon worker-1 kubectl uncordon Mark node as schedulable kubectl uncordon worker-1 kubectl drain Drain node in preparation for maintenance kubectl drain worker-1 --ignore-daemonsets kubectl taint nodes =: Add a taint to node kubectl taint nodes worker-1 gpu=true:NoSchedule.

Command Description Example kubectl top nodes Show CPU/Memory usage for nodes kubectl top nodes kubectl top pods Show CPU/Memory usage for pods kubectl top pods kubectl get events Show events in the cluster kubectl get events kubectl get all Show all resources kubectl get all.

Command Description Example kubectl create deployment --image= --dry-run=client -o yaml Generate deployment YAML kubectl create deploy nginx --image=nginx --dry-run=client -o yaml > [website] kubectl run --image= --dry-run=client -o yaml Generate pod YAML kubectl run nginx --image=nginx --dry-run=client -o yaml > [website] kubectl expose deployment --port= --dry-run=client -o yaml Generate service YAML kubectl expose deploy nginx --port=80 --dry-run=client -o yaml > [website].

Command Description Example kubectl apply -f Create/revision resource from file kubectl apply -f [website] kubectl apply -f Create/revision from all files in directory kubectl apply -f ./configs kubectl diff -f Show difference with live configuration kubectl diff -f [website] kubectl delete -f Delete resources from file kubectl delete -f [website].

Command Description Example kubectl config get-contexts List all contexts kubectl config get-contexts kubectl config current-context Show current context kubectl config current-context kubectl config use-context Switch to context kubectl config use-context prod-cluster kubectl config rename-context Rename context kubectl config rename-context gke_proj_zone_name prod.

Flag Description Example -n, --namespace Specify namespace kubectl get pods -n kube-system -A, --all-namespaces All namespaces kubectl get pods -A -o, --output Output format (yaml/json/wide/custom) kubectl get pod nginx -o yaml --watch, -w Watch for changes kubectl get pods -w --selector, -l Filter by label kubectl get pods -l app=nginx --field-selector Filter by field kubectl get pods --field-selector [website] --sort-by Sort output kubectl get pods --sort-by=.metadata.creationTimestamp.

Google Cloud, AWS, and Microsoft Azure have jointly revealed a new open-source project called Kube Resource Orchestrator (kro, pronounced.

Debugging is an essential part of a developer’s workflow—but it’s also one of the most time consuming. What if AI could streamline the process, helpin......

We can put an actual number on it. In machine learning, a loss function tracks the degree of error in the out......

Entendendo network drivers no Docker

Minha experiência com programação mudou completamente no dia em que eu descobri e aprendi a usar o Docker. Conseguir subir e gerenciar serviços na minha máquina e em produção, sem me preocupar com todos os problemas de trabalhar com aplicações em ambientes diferentes, fez uma grande diferença.

Mas algo que muita gente que está começando ou já usa o Docker acaba deixando passar é o conceito de redes e os tipos (drivers) de redes que existem, suas diferenças e quando usar cada uma.

Antes de falar sobre os tipos de rede disponíveis, vale a pena dar uma visão geral de como o conceito de redes é aplicado no Docker.

Quando falo de "rede em containers", estou me referindo à capacidade de containers se conectarem e se comunicarem entre si.

Talvez você já tenha precisado, por exemplo, criar um container com o nginx e outro com uma API REST (o nome do container poderia ser api ). O nginx precisa se comunicar com o api , ou pelo menos saber como chegar nele (através de um IP, por exemplo), e aí vem a pergunta: como fazer isso?

A resposta é sempre a mesma: por meio de uma rede interna entre os containers. E existem vários tipos de redes para alcançar esse objetivo!

Se você já usou o Docker Compose e usou o nome de um container dentro de outro container para fazer a comunicação (por exemplo, o container api se comunicando com o postgres usando o endereço postgres ), você já está usando uma rede criada automaticamente, que é do tipo bridge .

Com essa introdução feita, é hora de ir ao tópico principal do artigo.

As redes do tipo bridge são, provavelmente, as mais usadas no Docker. Elas permitem a comunicação básica entre containers na mesma máquina ( host ) e na mesma rede bridge .

Esse é o tipo de rede padrão quando você cria uma rede com docker network create ou quando há comunicação entre containers dentro de um Docker Compose.

Quando o Docker é iniciado, ele também cria uma rede bridge padrão, usada pelos containers que são criados sem especificar uma rede ou que estão fora do Compose. Essa rede é chamada de default bridge network e tem algumas diferenças em relação às redes bridge criadas pelo usuário (as chamadas user-defined bridge networks ).

A default bridge network não permite comunicação entre containers pelo nome (ou seja, não há resolução DNS), apenas pelo IP. E sim, estou ignorando a flag --link , que poderia ser usada para isso, mas não é recomendada.

Já as user-defined bridge networks permitem comunicação entre containers pelo nome e pelo IP. Além disso, por serem mais "específicas" (criadas para containers específicos), elas oferecem uma melhor isolação comparado à rede bridge padrão.

Você pode criar uma rede bridge com o comando:

docker network create nome_da_rede , e depois conectar um container a essa rede com docker network connect nome_da_rede nome_do_container .

Quando usar redes bridge : Quando você precisa de comunicação básica entre containers na mesma máquina.

As redes do tipo host permitem que o container se comunique com qualquer serviço exposto na máquina. Isso tem algumas implicações:

Você perde parte da isolação dos containers em relação à máquina, o que pode gerar problemas de segurança.

O container não recebe um IP exclusivo, então se ele tiver um serviço rodando na porta 80 , esse serviço estará disponível na mesma porta no IP da máquina (o que também pode ser um risco de segurança, especialmente se for um banco de dados e o firewall não estiver bem configurado).

, esse serviço estará disponível na mesma porta no IP da máquina (o que também pode ser um risco de segurança, especialmente se for um banco de dados e o firewall não estiver bem configurado). Por conta disso, não é possível mapear portas como nas redes bridge .

Você deve estar se perguntando, com tantos problemas, por que alguém usaria uma rede host em produção? A resposta é: performance.

Isso acontece porque você elimina camadas extras de rede e isolação, ganhando desempenho.

Uma particularidade interessante é que o Docker não cria uma rede virtual isolada nesse caso, logo não é possível criar a rede usando docker network create , em vez disso, basta criar o container com a flag --network host no comando docker run .

Quando usar redes host : Quando você precisa de alta performance e está disposto a sacrificar a segurança. Também vale a pena dar uma olhada nas redes IPvlan para casos semelhantes.

As redes do tipo overlay permitem a comunicação entre containers em máquinas diferentes.

São muito usadas no contexto do Docker Swarm para comunicação entre serviços em máquinas/nodes diferentes, mas também podem ser usadas em containers tradicionais.

As redes overlay podem ter a propriedade attachable , que permite que containers tradicionais (containers standalone) se conectem a essa rede.

Agora, um caso de uso interessante com as redes overlay : Em uma situação onde você precise rodar um serviço no Docker Swarm, para tirar uma vantagem especifica da ferramenta (por exemplo: blue-green deployments ou replicas), mas não quer rodar outros serviços na mesma modalidade e ainda precisa ter a comunicação entre eles, você pode fazer uso de uma rede overlay que esteja attachable , e ainda possuir a escalabilidade do Docker Swarm.

Você pode criar uma rede overlay com a opção attachable com o comando:

docker network create -d overlay --attachable nome_da_rede .

Quando usar redes overlay : Quando você precisa de comunicação entre containers ou serviços que estão em máquinas diferentes.

As redes IPvlan oferecem controle total sobre endereços IPv4 e IPv6 dos containers, usando uma rede virtual tratada como uma rede física da máquina. Elas oferecem boa performance, como a rede host , mas com maior controle e possibilidade de continuar isolando o tráfego do container.

Elas são mais complexas de configurar e exigem um bom conhecimento de redes.

Quando usar redes IPvlan : Quando você precisa de controle total sobre a rede e os endereços IPs, e tem o conhecimento necessário para configurar isso.

As redes Macvlan permitem que os containers sejam tratados como dispositivos independentes na rede da máquina/host. Cada container recebe seu próprio endereço MAC, como se fosse um dispositivo físico, como um computador ou celular.

Esse tipo de rede permite que os containers:

Comuniquem-se diretamente com a rede externa, como outros dispositivos na rede física.

Enviem e recebam pacotes diretamente da rede física, sem passar pela máquina/host.

Porém, isso pode causar problemas na rede física.

Quando usar redes Macvlan : Quando os containers precisam de acesso direto à rede física (como para monitorar o tráfego da rede).

Se você precisa isolar completamente um container da rede, pode usar a rede none .

Quando usar redes None : Quando você precisa de isolamento total de um container.

Pode ser que você nunca precise usar alguns desses tipos de rede, mas acredite, saber qual tipo de rede usar para comunicação entre containers ou serviços vai ser bem útil e vai evitar gambiarra (falo isso por experiência própria).

Kubectl is the command-line interface for interacting with Kubernetes clusters. It allows you to deploy applications, insp......

Web3 represents the next phase of the internet, shifting from centralized control to a decentralized, blockchain-powered ecosystem. This......

[website] is a lightweight jQuery plugin for highlighting words or phrases inside HTML elements.