관건은 이거다.
제대로 뜯어보자.
드디어 이해를 마쳤다.
인터넷에서 찾는 대부분의 정보는 InfluxDB1.x 버전이므로 나의 이슈 해결에 도움을 주지 못했다,,,
결국 Docs를 씹어먹기 시작.....
답을 찾아내었다.
먼저, 이전에도 말했듯 InfluxDB에는 3종류의 토큰이 있다.
All Access Token
: 말그대로 all access token이다.
다만, 위의 댓글 내용과 다른게 있다.
모든 orgs에 access할 수 있다고 하는데, 테스트해본 결과 불가능하다.
가령, org1과 org2가 있는 상황에서 org1에 token을 만들고 org list를 찍는 것은 가능하지만 org1의 토큰을 이용해서 org2에 있는 모든 작업을 할 수는 없다.
일부 가능한 것이 있는 것 같기도 한데, 그 레벨까지는 아직 확인이 어려운 것 같다.
아무튼, token의 경우 각 org에 종속되어 있는 것이라고 보는 게 맞다고 생각한다.
Write/Read Token
: 말 그대로 Write와 Read의 허가만 준 Token이다.Operator Token
: operation 레벨에서 사용하는 토큰이다.방금 확인해 본 결과, UI에서 확인이 되기는 한다. [사용자]'s Token
이라는 이름으로 보여진다.
이걸 몰라서 얼마나 힘들었던가...
따라서 생성할때부터 주의해주어야 한다,,,
생성할 때는
이렇게 생성해주면, 자동으로 config list에 org와 나의 config가 추가된 것을 볼 수 있다.
이제서야 비로소, All Access Token을 발급받으면 되는 것이다.,,!!!
이렇게 하면,,, 드디어 멀쩡하게 토큰이 생성되었다...
그리고 이 생성된 all-access-token을 가지고 config를 생성해주는 것이었다,,,
따라서 config와 token은 1:1 관계.
** 가장 심플한 테스트는 이것이다.
config를 생성한 다음에, export
를 이용해서 Environment variables의 token을 바꿔가며 테스트해보자.
influx server-config
명령어를 쳤을 때, 서버 컨픽에 대한 정보를 리턴해주는 것을 알 수 있다.하지만 발급받은 All Access Token을 이용했을 경우,
Operation 단계의 permission이 필요하다는 안내메시지가 나온다.
고로, OP Token을 가지고 있다가, permission 관련 내용이 나오면 OP Token을 이용해야 함이 적절하다!
org에 대한 내용은 token을 이용하면 상당히 단순하다.
token 생성은 org에 종속되어 있으므로, org1에다가 all access token1
을 만들어놓고 org2의 bucket에 접근하려고 하면? 당연히 안된다.
따라서 환경 변수를 컨트롤하여 버킷에 대한 접근 권한을 줘야 한다.
그러니까 이 token으로부터 나오는 전체적인 종속의 관계를..! 알 수 있게 된 것이다 ㅠ ㅠ ㅠ ㅠ