github.com/KyaXTeam/consul@v1.4.5/website/source/intro/index.html.md (about)

     1  ---
     2  layout: "intro"
     3  page_title: "Introduction"
     4  sidebar_current: "what"
     5  description: |-
     6    Welcome to the intro guide to Consul! This guide is the best place to start with Consul. We cover what Consul is, what problems it can solve, how it compares to existing software, and how you can get started using it. If you are familiar with the basics of Consul, the documentation provides a more detailed reference of available features.
     7  ---
     8  
     9  # Introduction to Consul
    10  
    11  Welcome to the intro guide to Consul! This guide is the best place to start
    12  with Consul. We cover what Consul is, what problems it can solve, how it compares
    13  to existing software, and how you can get started using it. If you are familiar
    14  with the basics of Consul, the [documentation](/docs/index.html) provides a more
    15  detailed reference of available features.
    16  
    17  ## What is Consul?
    18  
    19  Consul is a service mesh solution providing a full featured control plane
    20  with service discovery, configuration, and segmentation functionality. Each
    21  of these features can be used individually as needed, or they can be used
    22  together to build a full service mesh. Consul requires a data plane and
    23  supports both a proxy and native integration model. Consul ships with a
    24  simple built-in proxy so that everything works out of the box, but also
    25  supports 3rd party proxy integrations such as Envoy.
    26  
    27  The key features of Consul are:
    28  
    29  * **Service Discovery**: Clients of Consul can register a service, such as
    30    `api` or `mysql`, and other clients can use Consul to discover providers
    31    of a given service. Using either DNS or HTTP, applications can easily find
    32    the services they depend upon.
    33  
    34  * **Health Checking**: Consul clients can provide any number of health checks,
    35    either associated with a given service ("is the webserver returning 200 OK"), or
    36    with the local node ("is memory utilization below 90%"). This information can be
    37    used by an operator to monitor cluster health, and it is used by the service
    38    discovery components to route traffic away from unhealthy hosts.
    39  
    40  * **KV Store**: Applications can make use of Consul's hierarchical key/value
    41    store for any number of purposes, including dynamic configuration, feature flagging,
    42    coordination, leader election, and more. The simple HTTP API makes it easy to use.
    43  
    44  * **Secure Service Communication**: Consul can generate and distribute TLS
    45    certificates for services to establish mutual TLS connections.
    46    [Intentions](/docs/connect/intentions.html)
    47    can be used to define which services are allowed to communicate.
    48    Service segmentation can be easily managed with intentions that can
    49    be changed in real time instead of using complex network topologies
    50    and static firewall rules.
    51  
    52  * **Multi Datacenter**: Consul supports multiple datacenters out of the box. This
    53    means users of Consul do not have to worry about building additional layers of
    54    abstraction to grow to multiple regions.
    55  
    56  Consul is designed to be friendly to both the DevOps community and
    57  application developers, making it perfect for modern, elastic infrastructures.
    58  
    59  ## Basic Architecture of Consul
    60  
    61  Consul is a distributed, highly available system. This section will cover the
    62  basics, purposely omitting some unnecessary detail, so you can get a quick
    63  understanding of how Consul works. For more detail, please refer to the
    64  [in-depth architecture overview](/docs/internals/architecture.html).
    65  
    66  Every node that provides services to Consul runs a _Consul agent_. Running
    67  an agent is not required for discovering other services or getting/setting
    68  key/value data. The agent is responsible for health checking the services
    69  on the node as well as the node itself.
    70  
    71  The agents talk to one or more _Consul servers_. The Consul servers are
    72  where data is stored and replicated. The servers themselves elect a leader.
    73  While Consul can function with one server, 3 to 5 is recommended to avoid
    74  failure scenarios leading to data loss. A cluster of Consul servers is recommended
    75  for each datacenter.
    76  
    77  Components of your infrastructure that need to discover other services
    78  or nodes can query any of the Consul servers _or_ any of the Consul agents.
    79  The agents forward queries to the servers automatically.
    80  
    81  Each datacenter runs a cluster of Consul servers. When a cross-datacenter
    82  service discovery or configuration request is made, the local Consul servers
    83  forward the request to the remote datacenter and return the result.
    84  
    85  ## Next Steps
    86  
    87  * See [how Consul compares to other software](/intro/vs/index.html) to assess how it fits into your
    88  existing infrastructure.
    89  * Continue onwards with the [getting started guide](https://learn.hashicorp.com/consul/getting-started/install)
    90  to get Consul up and running.