项目文件夹

文件
Asim Aslam 96280678ee Expose framework primitives via API gateway and MCP with auth control (#2925)
* feat: expose framework primitives via API gateway and MCP

Add registry, store, and broker as both HTTP routes and MCP tools
so AI agents and HTTP clients can inspect and operate the framework.

API gateway (/micro/* namespace):
  GET  /micro/registry         List registered services
  GET  /micro/registry/{name}  Describe a service
  GET  /micro/store            List store keys
  GET  /micro/store/{key}      Read a record
  POST /micro/store/{key}      Write a record
  POST /micro/broker/{topic}   Publish a message

MCP gateway (micro_* tool prefix):
  micro_registry_list    List services
  micro_registry_get     Describe a service
  micro_store_list       List keys
  micro_store_read       Read a record
  micro_store_write      Write a record
  micro_broker_publish   Publish a message

Framework tools use a Handler field on the MCP Tool struct for
direct dispatch (no RPC). Service tools continue to use RPC.
Rate limiters and circuit breakers are applied to framework
tools the same as service tools.

* fix: make framework internals opt-in on API and MCP gateways

Framework primitives (registry, broker, store) are now only
exposed when explicitly enabled:

API gateway:  micro api --internal
MCP gateway:  Options{Internal: true}

Off by default — user services are always exposed, framework
internals require the flag. Banner output only shows framework
routes when enabled.

* fix: always expose framework internals, gate by auth in production

Revert the --internal flag approach. Framework primitives (registry,
broker, store) are now always exposed:

- micro api: /micro/* routes always available (dev tool)
- MCP gateway: micro_* tools always registered. When Auth is
  configured (production), they require micro:admin scope.
  Without Auth (dev), they're open — same as all other tools.

This follows the existing pattern: micro run/api = dev (open),
micro server = production (auth + scopes). Framework internals
follow the same security model as user services.

Remove the Internal option from MCP Options. Remove --internal
flag from micro api.

Note: scope persistence depends on the store backend. The default
in-memory store does not survive restarts. Use MICRO_STORE=file
for persistent scopes in production.

* fix: correct DefaultStore comment — it's file-backed, not memory

* fix(server): don't recreate deleted admin user on restart

When the default admin account is deleted via the dashboard, set
a marker key (auth/.admin-deleted) in the store. On startup, skip
admin creation if the marker exists. This prevents the default
admin/micro credentials from reappearing after restart when the
user has intentionally removed them.

* fix: improve agent playground first-run UX and fix doc 404s

Agent playground:
- Add setup hint in empty state explaining how to get started
  (click Settings, enter API key, type a prompt)
- Hide hint automatically when API key is already configured
- Add all 7 providers to dropdown (was only OpenAI + Anthropic)
- Include CLI fallback suggestion (micro chat)

Docs:
- Fix .md links to .html across all doc pages — Jekyll serves
  .html files, not .md. Fixes 404s including the micro run guide.

---------

Co-authored-by: Claude <noreply@anthropic.com>
2026-06-03 11:05:51 +01:00

4.6 KiB

layout
layout
default

Configuration

Configuration

Go Micro follows a progressive configuration model so you can start with zero setup and layer in complexity only when needed.

Levels of Configuration

  1. Zero Config (Defaults)
    • mDNS registry, HTTP transport, in-memory broker/store
  2. Environment Variables
    • Override core components without code changes
  3. Code Options
    • Fine-grained control via functional options
  4. External Sources (Future / Plugins)
    • Configuration loaded from files, vaults, or remote services

Core Environment Variables

Component Variable Example Purpose
Registry MICRO_REGISTRY MICRO_REGISTRY=consul Select registry implementation
Registry Address MICRO_REGISTRY_ADDRESS MICRO_REGISTRY_ADDRESS=127.0.0.1:8500 Point to registry service
Broker MICRO_BROKER MICRO_BROKER=nats Select broker implementation
Broker Address MICRO_BROKER_ADDRESS MICRO_BROKER_ADDRESS=nats://localhost:4222 Broker endpoint
Transport MICRO_TRANSPORT MICRO_TRANSPORT=nats Select transport implementation
Transport Address MICRO_TRANSPORT_ADDRESS MICRO_TRANSPORT_ADDRESS=nats://localhost:4222 Transport endpoint
Store MICRO_STORE MICRO_STORE=postgres Select store implementation
Store Database MICRO_STORE_DATABASE MICRO_STORE_DATABASE=app Logical database name
Store Table MICRO_STORE_TABLE MICRO_STORE_TABLE=records Default table/collection
Store Address MICRO_STORE_ADDRESS MICRO_STORE_ADDRESS=postgres://user:pass@localhost:5432/app?sslmode=disable Connection string
Server Address MICRO_SERVER_ADDRESS MICRO_SERVER_ADDRESS=:8080 Bind address for RPC server

Example: Switching Components via Env Vars

# Use NATS for broker and transport, Consul for registry
export MICRO_BROKER=nats
export MICRO_TRANSPORT=nats
export MICRO_REGISTRY=consul
export MICRO_REGISTRY_ADDRESS=127.0.0.1:8500

# Run your service
go run main.go

No code changes required. The framework internally wires the selected implementations.

Equivalent Code Configuration

service := micro.NewService(
    micro.Name("helloworld"),
    micro.Broker(nats.NewBroker()),
    micro.Transport(natstransport.NewTransport()),
    micro.Registry(consul.NewRegistry(registry.Addrs("127.0.0.1:8500"))),
)
service.Init()

Use env vars for deployment level overrides; use code options for explicit control or when composing advanced setups.

Precedence Rules

  1. Explicit code options always win
  2. If not set in code, env vars are applied
  3. If neither code nor env vars set, defaults are used

Discoverability Strategy

Defaults allow local development with zero friction. As teams scale:

  • Introduce env vars for staging/production parity
  • Consolidate secrets (e.g. store passwords) using external secret managers (future guide)
  • Move to service mesh aware registry (Consul/NATS JetStream)

Validating Configuration

Enable debug logging to confirm selected components:

MICRO_LOG_LEVEL=debug go run main.go

You will see lines like:

Registry [consul] Initialised
Broker [nats] Connected
Transport [nats] Listening on nats://localhost:4222
Store [postgres] Connected to app/records

Patterns

Twelve-Factor Alignment

Environment variables map directly to deploy-time configuration. Avoid hardcoding component choices so services remain portable.

Multi-Environment Setup

Use a simple env file per environment:

# .env.staging
MICRO_REGISTRY=consul
MICRO_REGISTRY_ADDRESS=consul.staging.internal:8500
MICRO_BROKER=nats
MICRO_BROKER_ADDRESS=nats.staging.internal:4222
MICRO_STORE=postgres
MICRO_STORE_ADDRESS=postgres://staging:pass@pg.staging.internal:5432/app?sslmode=disable

Load with your process manager or container orchestrator.

Troubleshooting

Symptom Cause Fix
Service starts with memory store unexpectedly Env vars not exported `env
Consul errors about connection refused Wrong address/port Check MICRO_REGISTRY_ADDRESS value
NATS connection timeout Server not running Start NATS or change address
Postgres SSL errors Missing sslmode param Append ?sslmode=disable locally