satoshipay / docker-stellar-horizon Goto Github PK

When trying to start docker compose, I was seeing the following in the logs...

stellar-horizon-postgres_1 | AS $$ SELECT $1 $$
stellar-horizon_1 | 2019/04/26 11:09:11 Invalid config: network-passphrase is blank. Please specify --network-passphrase on the command line or set the NETWORK_PASSPHRASE environment variable.
docker-stellar-horizon_stellar-horizon_1 exited with code 1

If I add - NETWORK_PASSPHRASE=Public Global Stellar Network ; September 2015 to the horizon ENV...

 stellar-horizon:
    image: satoshipay/stellar-horizon:0.17.2
    restart: on-failure
    ports:
    - 8000:8000
    environment:
      - DATABASE_URL=postgres://postgres@stellar-horizon-postgres/stellar-horizon?sslmode=disable
      - STELLAR_CORE_DATABASE_URL=postgres://postgres@stellar-core-postgres/stellar-core?sslmode=disable
      - STELLAR_CORE_URL=http://stellar-core:11626
      - NETWORK_PASSPHRASE=Public Global Stellar Network ; September 2015
      - INGEST=true

and now I can access the server on http://localhost:8000/

I am attempting to map the configuration here
https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_testnet.cfg to a docker compose file to leverage Stellar testnet. I am making some progress but wondered if anyone has one this prior (and we could have this be another config template for users to play with).

Horizon 0.20.1 has been out for 6 days: https://github.com/stellar/go/releases/tag/horizon-v0.20.1
It would be nice to have the latest version.

New upstream release: https://github.com/stellar/horizon/releases/tag/v0.11.1

Released last week: https://github.com/stellar/go/releases/tag/horizon-v0.13.0

This enables users to pass the passwords separately, e.g., via Kubernetes secrets.

Stellar core automatically migrates its database on start up if it's not migrated yet and there's no way to control that behaviour. I think that this image should also do the same unconditionally because:

1. It wouldn't make it any less flexible than stellar core and everyone running horizon must also deal with stellar core's limitations
2. It would make the behaviour consistent and avoid requiring manual intervention during database upgrades.

I'd also be happy to have this configurable via an environment variable. Same for core, but it would require a code change for core. See stellar/stellar-core#1912

I'm running into an issue in CI where if horizon starts up before everything else and it hasn't performed db initialization, it can get into a broken state where it's running but never initialized the database. I don't know if this is a horizon bug, a docker image startup script bug or both, but I think this issue can be worked around in the startup script by checking more specifically that db initialization was done.

Logs:

stellar-horizon_1     | 2019-02-05T17:39:52.920368516Z Initializing Horizon database...
stellar-horizon_1     | 2019-02-05T17:39:53.004165677Z Horizon database initialization failed (possibly because it has been done before)
stellar-horizon_1     | 2019-02-05T17:39:53.004197994Z time="2019-02-05T17:39:52.998Z" level=error msg="connect failed: pq: the database system is starting up" pid=7 
stellar-horizon_1     | 2019-02-05T17:39:53.581502682Z time="2019-02-05T17:39:53.581Z" level=warning msg="could not load stellar-core info: http request errored: Get http://<redacted>:11626/info: dial tcp 172.18.0.2:11626: connect: connection refused" pid=1 
stellar-horizon_1     | 2019-02-05T17:39:53.590863575Z time="2019-02-05T17:39:53.590Z" level=info msg="Starting horizon on :8000 (ingest: true)" pid=1 
stellar-horizon_1     | 2019-02-05T17:39:54.005158450Z time="2019-02-05T17:39:54.005Z" level=error msg="failed to load operation fee stats state" err="get failed: pq: relation "history_ledgers" does not exist" pid=1 stack="[main.go:43 session.go:106 main.go:322 app.go:206 app.go:313 asm_amd64.s:1333]" 
stellar-horizon_1     | 2019-02-05T17:39:54.006246193Z time="2019-02-05T17:39:54.006Z" level=error msg="failed to load ledger state" err="get failed: pq: relation "history_ledgers" does not exist" pid=1 stack="[main.go:43 session.go:106 main.go:316 app.go:176 app.go:312 asm_amd64.s:1333]"