[증인노드] 비교적 손쉽게 증인노드 업데이트 하는 방법
개요
참조 : 스팀도커 - someguy123 를 기반으로 업데이트 작업을 진행 합니다.
비교적 손쉽게 증인노드를 업데이트 하는 방법을 공유 합니다.
- 폴더 경로는 개인 설치 위치에 따라 약간씩 상이 할 수 있으니 이 점 유의 바랍니다.
TL;DR
소스 빌드가 완료 후 도커 이미지 변경이 핵심입니다.
- 작업경로 이동
- .env 변경
- 소스빌드
- 지갑 업데이트 ( 증인 정보 업데이트 - 비활성 )
- 노드 중지
- 노드 기동
- 지갑 업데이트 ( 증인 정보 업데이트 - 활성 )
상세 작업
1. 작업경로 이동
cd steem-docker
2. .env 변경
소스 빌드에 필요한
STEEM_SOURCE정보를 변경 합니다.
vi ~/steem-docker/.env
STEEM_SOURCE="https://github.com/steem-witnesses/steem.git"
3. 소스빌드
약 20 -30분 정도의 시간을 기다리면 소스 빌드가 완료 되며 도커 이미지가 추가 됩니다.
ex) steem:0.22.888 도커 이미지가 추가 됨
| REPOSITORY | TAG | IMAGE ID | CREATED | SIZE |
|---|---|---|---|---|
| steem | 0.22.888 | 53b81cbdbc81 | 2 hours ago | 1.49GB |
| someguy123/steem | v0.22.5-mira | 73441fe0048d | 2 weeks ago | 1.49GB |
| ubuntu | bionic | 72300a873c2c | 6 weeks ago | 64.2MB |
./run.sh build 0.22.888
- 스팀 소스 : STEEM_SOURCE="https://github.com/steem-witnesses/steem.git"
- 태깅 적용 : https://github.com/steem-witnesses/steem/tree/0.22.888
위 STEEM_SOURCE 에 명시된 태깅(TAGS) 정보를 기준으로 업데이트를 수행합니다. 위 같이 하면 0.22.888 태깅 정보를 기반으로 빌드를 수행하겠다는 이야기
4. 증인정보 업데이트 (비활성)
STM1111111111111111111111111111111114T1Anm테스트키로 증인 정보를 업데이트(비활성) 한다
./run.sh wallet
unlock "로컬지갑 암호"
update_witness "계정명" "URL정보" "STM1111111111111111111111111111111114T1Anm" {"account_creation_fee":"3.000 STEEM","maximum_block_size":65536,"sbd_interest_rate":0} true
5. 노드 중지
./run.sh stop
6. .env 변경
구동 시킬 docker 이미지명을 변경합니다. ( 이전 .env 수정 시 미리 추가 후 본 과정을 생략해도 무방합니다. )
vi ~/steem-docker/.env
DOCKER_IMAGE="steem:0.22.888"
7. 노드 시작
./run.sh start
8. 증인정보 업데이트 (활성)
uggest_brain_key의 public key 정보를 올바르게 업데이트(활성) 한다
./run.sh wallet
unlock "로컬지갑 암호"
update_witness "계정명" "URL정보" "suggest_brain_key의 public key" {"account_creation_fee":"3.000 STEEM","maximum_block_size":65536,"sbd_interest_rate":0} true
맺음말
- 소스 빌드가 완료 후 도커 이미지 변경이 핵심입니다.
- 위와 같이 하면 downtime 을 최소화 할 수 있습니다 : )
상위 20위의 경우 사이닝키를 백업 노드의 것으로 변경한 뒤 업데이트 이후 되돌림으로써 다운타임이 없도록 해야합니다.
위에 기술한 방식은 downtime이 build 하는 시간이 포함되어 매우 길어 지는 것이 맞습니다. 하지만 아래와 같은 방식으로 적용해본 결과 잘 되네요 :)
참고로 이번 경우와 같이 리플레이가 필요 없는 경우에는
위 방식으로 해도 downtime 이 0에 수렴 하는 것을 확인 할 수 있었네요 :)
(물론 0는 아니지만 미싱블록 기준으로는 0 이여서 ^^;)
단, 리플레이가 필요한 경우에는 말하신 방식대로
위 방식으로 downtime 을 최소화 하는 것이 좋을거 같고여 :)
의견 감사합니다.