[WARNING SystemVerification]: this Docker version is not on the list of validated versions: 20.10.1. Latest validated version: 19.03
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local master-stg] and IPs [10.96.0.1 192.168.100.119]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost master-stg] and IPs [192.168.100.119 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost master-stg] and IPs [192.168.100.119 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 13.002889 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.20" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node master-stg as control-plane by adding the labels "node-role.kubernetes.io/master=''" and "node-role.kubernetes.io/control-plane='' (deprecated)"
[mark-control-plane] Marking the node master-stg as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: t4tcwj.22xh9lzstu56qyrb
구버전을 사용하다 2.3으로 업데이트하면서 블로그 글을 보면서 많은 도움을 받았는데 궁금한게 있어 문의 댓글 남깁니다.
현재 윈도우XP에 2.3 버전으로 업데이트하여(기존 0.9 였나?) 사용중에 있는데 2가지 문제가 해결이 안되네요.
1. 2.3 버전으로 업데이트후 레드마인에서 이슈 등록이나 수정등을 할때 입력 버튼을 누르면 완료되기까지 한참이 걸립니다.
대략 10~20초 정도?
업데이트전인 기존 버전에선 바로 등록이 되었는데 큰 차이가 날 정도로 느려졌습니다 ㅜㅜ
2. PNG 내보내기시 internal error이 발생하는데 아무리 검색해봐도 이전 버전에서 해결되었다라는 것만 보이네요.
폰트 문제인가 싶어 환경 설정 파일에서 폰트 경로는 추가를 한 상태 입니다.
설정 정보에서 "RMagick 사용 가능 (선택적)" 이라고 체크되어 있고 내보내기에 PNG가 표시되는걸 보면 프로그램 설치는 정상적인것 같은데 에러나는 이유를 모르겠네요.
1. 웹 동작과 관련해서는 [ log/production.log ] 파일을 살펴보시길 권장합니다. 제가 이슈 새로 생성해본 내용은 아래와 같네요.
Started GET "/redmine/projects/test/issues/new" for 10.0.2.2 at 2013-05-16 00:26:29 +0900
Processing by IssuesController#new as HTML
Parameters: {"project_id"=>"test"}
Current user: admin (id=1)
Rendered issues/_form_custom_fields.html.erb (11.0ms)
Rendered issues/_attributes.html.erb (26.7ms)
Rendered issues/_form.html.erb (46.1ms)
Rendered attachments/_form.html.erb (5.3ms)
Rendered issues/new.html.erb within layouts/base (59.4ms)
Rendered plugins/redmine_banner/app/views/banner/_project_body_bottom.html.erb (2.2ms)
Completed 200 OK in 189ms (Views: 67.5ms | ActiveRecord: 25.8ms)
Started POST "/redmine/projects/test/issues" for 10.0.2.2 at 2013-05-16 00:27:21 +0900
Processing by IssuesController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"rhb1F6cW4HMS2nO/U1FqbBNbbJJSOKLSZ+znmzRs2ak=", "issue"=>{"is_p$
Current user: admin (id=1)
Rendered mailer/_issue.text.erb (1.3ms)
Rendered mailer/issue_add.text.erb within layouts/mailer (3.8ms)
Rendered mailer/_issue.html.erb (65.8ms)
Rendered mailer/issue_add.html.erb within layouts/mailer (68.0ms)
Redirected to http://127.0.0.1/redmine/issues/1
Completed 302 Found in 296ms (ActiveRecord: 40.7ms)
2. PNG로 내보내는 것 역시 마찬가지로 log 파일을 확인해보시기 바랍니다. 한글 출력에 문제가 있는 것 말고는 전 잘되네요.
Started GET "/redmine/projects/test/issues/gantt.png?month=5&months=6&year=2013&zoom=2" for 10.0.2.2 at 2013-05-1$
Processing by GanttsController#show as PNG
Parameters: {"month"=>"5", "months"=>"6", "year"=>"2013", "zoom"=>"2", "project_id"=>"test"}
Current user: admin (id=1)
Rendered text template (0.0ms)
Sent data test-gantt.png (3.8ms)
Completed 200 OK in 307ms (Views: 3.6ms | ActiveRecord: 15.9ms)
에러라는 것이 언제나 그렇지만, 재연이 안되는 것은 답변 드리기가 조금 어렵네요.
제 환경에서 error.log 파일 내용을 보면 아래와 같습니다.
[Thu May 16 00:57:48 2013] [notice] mod_python: Creating 8 session mutexes based on 6 max processes and 25 max threads.
[Thu May 16 00:57:48 2013] [notice] mod_python: using mutex_directory /tmp
[Thu May 16 00:57:48 2013] [notice] Apache/2.2.20 (Ubuntu) Phusion_Passenger/3.0.19 mod_python/3.3.1 Python/2.7.2+ configured -- resuming normal operations
그런데, redmine님이 남긴 로그를 보면 조금 이상하긴 하네요.
Passenger 버전을 강제로 다운시켜보시면 어떨까 싶기는 하는데,
그 문제로 인한 것인지 확신은 없습니다.
SSH가 훌륭한 놈이라는 것은 분명하지만,
계정 관리에 있어서 부족함이 있는 것 또한 분명하다.
Git에 있어서도 다양하고 디테일한 권한 설정 등이 필요한데,
이 부분을 SSH는 충분히 채워주지 못하고 있다.
그래서, Git을 위한 계정(권한) 관리 도구들이 계속 나타나고 있다.
과거에는 Gitosis 라는 것을 주로 사용했으나 기능이나 사용상의 편의성에 있어서 부족함이 보여서
새로운 Gitolite 라는 것이 나타났고, 최근에는 거의 대부분 Gitolite를 사용하고 있다.
사실 일반적인 경우 Gitosis만 가지고도 대부분 처리가 가능하나,
왠지 더 최근의 보다 더 막강한 Gitolite를 적용하곤 하는 것도 없지 않아 있는 것 같다.
물론 나의 경우에도 마찬가지다! 최신병에 걸린 죄로.... Gitolite에 대해서 연구를 해보겠다!!!
Gitolite를 설치하는 방법은 당연하게도 패키지 설치와 소스 설치가 있고...
여기에서는 소스를 가지고 설치하는 과정으로 설명을 할 것이다.
[ 전면수정 ]
- 내가 바보같아서인지, 이 놈의 Gitolite에 대해서 친절하게 설명해 놓은 자료가 안보인다.
- 가끔 친절한척 자세히 적어놓은 것들이 있지만, 따라하다보면 대체 뭘하는 것인지 모르겠는 그런 것이 대부분이다.
- 더더욱 힘들게 하는 것은 Gitolite가 최근 g2 버전에서 g3로 바뀌면서 설치 과정들이 바뀌었다.
- 그래서 예전 기억을 더듬어 차근차근 포스팅을 해나가다가... 좌절! 결국 대폭 수정 작업!!! 짜증 확!!! ㅠㅠ
- 꼭 위와 같이 구성해야하는 것은 절대 아니다.
- 아래 설명하는 내용을 잘 읽어보고 어떻게 구성해야하는지 각자 결정하면 된다.
- 위의 직사각형은 각 계정을 의미한다.
- [ git-repo ] 계정은 Git repository를 운영하기 위한 계정이다.
- [ gitolite ] 계정은 Gitolite를 관리하기 위한 관리자 계정이다.
- [ user ] 계정은 그냥 여러분이 사용하는 Ubuntu의 기본 계정이다.
- 위 그림에 대한 설명은 아래 내용들을 하나씩 따라하면 알 수 있을 것이다.
3. 계정 생성
- SSH 환경에서 여러 개발자들을 지원해주기 위해서는 Linux 계정을 그 숫자만큼 만들어줘야 했다.
- Gitolite를 적용하게 되면 Linux 계정을 만들어주지 않고도 Git 계정을 만들어 줄 수 있다.
- 대표 계정 하나로 나머지를 모두 커버하는 것이다.
$ sudo adduser gitolite
$ sudo adduser git-repo
- [ gitolite, git-repo ]라는 계정을 추가해주자.
4. Public Key 등록
- 현재 작업중인 계정에서 다른 계정에 접근하기 위해 Public-Key를 등록해주자.
- 지금 사용중인 user의 계정에서 gitolite, git-repo 계정으로 ssh 접근을 바로(패스워드 없이) 하기 위해서
user 계정의 공개키를 넣어주는 것이다.
$ ssh-keygen
$ ls -al ~/.ssh/
- [ ~/.ssh/ ] 계정의 홈디렉토리 밑에 있는 '.ssh/' 디렉토리 밑의 파일들을 우선 확인하고,
- [ id_rsa ], [ id_rsa.pub ] 파일들이 안보이면 [ ssh-keygen ]으로 생성을 해주면 된다.
- [ git-repo ] 계정으로 작업을 하기 위해서 해당 계정으로 접속한다.
- [ git-repo ]의 홈디렉토리에서 Gitolite를 clone하면 된다.
- 그런데, 여기에서 중요한 점을 하나 집고 넘어가야 한다.
- 웹에서 검색이 되는 Gitolite의 설치가이드 대부분과 지금 현재 상황이 맞지 않는다는 점이다.
- 그 이유는 버전이 틀리다!!! 기존 Gitolite 대부분은 "g2" 버전이고, 지금은 "g3"다.
- 그래서 설치 스크립트가 틀리다.
- 2012.04.17에 g3가 릴리스가 되어서인지, 이와 관련한 자료는 거의 없다.
6. install
- 다운로드 받은 Gitolite를 설치해보자.
$ ./gitolite/install
- 그냥 'install'만 실행하면 일단 끝이다.
- 만약 다른 디렉토리에 설치하고 싶으면 [ ./gitolite/install -to /srv/install/gitolite ]와 같이 사용한다.
- 여기에서 설치하는 것은 실행할 수 있는 binary들이다.
- 이제 이어서 'setup'을 해야하는데, 관리자 계정의 공개키가 필요하다.
- 앞에서 만든 계정 중에서 우리는 [ gitolite ]라는 이름으로 관리자 계정을 만들어 놓았다.
- install 후에 사용할 수 있게 된 [ ./gitolite/src/gitolite ] 명령어를 이용하여 setup을 하는데,
- [ gitolite ] 계정의 공개키를 관리자로 등록하는 것이다.
- Gitolite는 하나의 repository로 관리를 하게 된다. 위 화면에서 보는 바와 같이 [ gitolite-admin.git ]이 그것이다.
- 해당 repository에 자료를 넣을 수 있는 관리자는 방금 전에 등록한 공개키로 인하여 [ gitolite ] 계정이다.
- 친절하게도 테스트 해볼 수 있게 [ testing.git ] repository도 제공을 해준다.
7. clone
- [ gitolite-admin.git ] repository를 clone 받아서 확인을 해보도록 하겠다.
$ ssh gitolite@localhost
$ mkdir repositories
- Gitolite에 관리자로 등록시킨 [ gitolite ] 계정으로 접속하자.
- clone 받을 디렉토리도 'repositories'라는 이름으로 만들어두자.
▶ 여기에서 Gitolite를 처음 접하는 분들을 위한 질문~!!!!!!!
- 위와 같이 만든 [ Gitolite를 적용한 Git ]에 어떻게 접근을 할까?!
▷ 정답은 대표 계정 1개로 접근을 한다!
- 이 포스팅 내용대로라면 여기에서는 [ git-repo ] 계정
- [ gitolite ] 계정이 [ git-repo ] 계정에 접근을 하려고 하면,
- 'gitolite' 계정의 private key에 대응하는 public key를 찾는데,
- [ Gitolite ]가 이 부분에 개입을 해서 등록된 public key를 기반으로 권한을 확인하고
- repository에 대한 접근 권한을 조정한다.
- 이 부분에 대해서 오랫동안 고민해보질 못해서인지 쉽게 설명은 안되는데, 위의 글과 그림을 잘 봐보면....^^
포스팅 감사히 잘 봤습니다 ^^
코드리뷰 + 권한 관리를 위하여 Gerrit을 사용하기는 했었는데 Gitolite 는 처음 접해보네요..
포스팅을 쭉~ 읽어봤는데 제가 기존에 사용하던 방식이랑은 많이 달라서 이해가 잘 되지 않는 부분도 있네요..
시간을 두고 실습 해보면서 자세히 정독 해야할 것 같습니다.
포스팅 감사합니다 ^^
정말 큰 도움이 되었습니다. 알기 쉽게 정리가 잘 된 것 같아요. 다만 chani 계정의 공개키를 git-repo 계정에 추가한 부분 때문에 chani 계정에서 clone 에러가 발생하여 조금 어려움을 겪었습니다. 사실 어떻게 보면 ssh-copy-id 부분은 굳이 필요한 부분은 아닌거죠?? 아무튼 좋은 글 감사합니다!!
안녕하세요! 이해가 될 듯 말 듯한 부분이 있어서 질문을 드립니다.
위 예제에서 chani 계정으로 접근이 안되잖아요?
gitolite 계정으로 로그인해서 conf/gitolite.conf에 chani 추가해주고 keydir에 chani.pub 추가한 다음 commit/push 하고 다시 chani 계정에서 위 clone 시도를 다시 하면 그 때는 되는 건가요?
