ssh agent forwarding(에이전트 포워딩)에 sudo를 사용할 때 참고할만한 싸이트


https://gist.github.com/scottjacobsen/4281310




> sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK git clone git@github.com:my-github-account/my-repo.git


Posted by 김용환 '김용환'



spark 앱을 로컬(Intellij)에서 테스트/실행할 때 

아래와 같이 SparkDriver 를 바인딩하지 못해 에러가 나는 경우가 종종 발견할 수 있다.




WARN Utils: Service 'sparkDriver' could not bind on port 0. Attempting port 1.


..java.net.BindException: Can't assign requested address: Service 'sparkDriver' failed after 16 retries!






이럴 때는 다음 코드를 참조해서 SparkConf 인스턴스를 생성할 때 다음 코드로 수정한다. 더 이상 발생하지 않을 것이다.



lazy val sparkConf: SparkConf  = new SparkConf().setMaster("local[1]") //상관없음

                              .setAppName("spark-test") 

                              .set("spark.driver.host", "localhost"); // 반드시 필수




Posted by 김용환 '김용환'


rawdata를 case class로 정의해서 spark Dataset으로 encoding할 때 아래 에러가 발생할 수 있다.



Error:(14, 31) Unable to find encoder for type Flight. An implicit Encoder[Flight] is needed to store Flight instances in a Dataset. Primitive types (Int, String, etc) and Product types (case classes) are supported by importing spark.implicits._  Support for serializing other types will be added in future releases.

    val flights = flightsDF.as[Flight]

Error:(14, 31) not enough arguments for method as: (implicit evidence$2: org.apache.spark.sql.Encoder[Flight])org.apache.spark.sql.Dataset[Flight].

Unspecified value parameter evidence$2.

    val flights = flightsDF.as[Flight]



먼저 case class를 main 앞에 위치시키고 import spark.implicits._ 를 main 안에 위치한다.



case class Flight(DEST_COUNTRY_NAME: String, 
           ORIGIN_COUNTRY_NAME: String, count: BigInt)

object FlightMain extends SparkHelper {
def main(args: Array[String]): Unit = {

// 3.2
import sparkSession.implicits._

val flightsDF = sparkSession.read.parquet("origin-source/data/flight-data/parquet/2010-summary.parquet")
val flights = flightsDF.as[Flight]


Posted by 김용환 '김용환'



jenkins pipeline 공부에 도움이 되는 것 같아 링크 중심으로 정리했다.



1. pipeline


pipeline 개념, 공식 문서

https://jenkins.io/doc/book/pipeline/


한글 - 사례

https://kingbbode.tistory.com/35


https://jojoldu.tistory.com/355


https://limsungmook.github.io/2016/11/09/jenkins-pipeline/




2. multi-branch


특정 branch 뿐 아니라 pr, branch도 테스트할 수 있다. jenkinsfile(pipeline)을 포함하면 금상첨화이다.


공식 문서

https://jenkins.io/doc/book/pipeline/multibranch/


사례


https://www.praqma.com/stories/jenkins-pipeline/




3. blue ocean에서 pipeline 편집하기


공식 문서

https://jenkins.io/doc/tutorials/create-a-pipeline-in-blue-ocean/


쉽게 파이프라인을 구성할 수 있다. 



ci/cd 실제 사례



Posted by 김용환 '김용환'


 데비안/우분투에서 다음과 같은 에러가 발생한다면 호스트의 설정을 변경해야 한다.



WARNING: Your kernel does not support swap limit capabilities. Limitation discarded.

WARNING: No memory limit support

WARNING: No swap limit support




참고 자료는 다음과 같다.

(호스트 머신의 재시작을 잊지 말자!)





https://docs.docker.com/install/linux/linux-postinstall/



Your kernel does not support cgroup swap limit capabilities

On Ubuntu or Debian hosts, You may see messages similar to the following when working with an image.

WARNING: Your kernel does not support swap limit capabilities. Limitation discarded.

This warning does not occur on RPM-based systems, which enable these capabilities by default.

If you don’t need these capabilities, you can ignore the warning. You can enable these capabilities on Ubuntu or Debian by following these instructions. Memory and swap accounting incur an overhead of about 1% of the total available memory and a 10% overall performance degradation, even if Docker is not running.

  1. Log into the Ubuntu or Debian host as a user with sudo privileges.

  2. Edit the /etc/default/grub file. Add or edit the GRUB_CMDLINE_LINUX line to add the following two key-value pairs:

    GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"
    

    Save and close the file.

  3. Update GRUB.

    $ sudo update-grub
    

    If your GRUB configuration file has incorrect syntax, an error occurs. In this case, repeat steps 2 and 3.

    The changes take effect when the system is rebooted.


Posted by 김용환 '김용환'


키바나 7.0부터 mobile을 지원한다.. (beta 1)




https://github.com/elastic/kibana/issues/2563


https://github.com/elastic/kibana/pull/29896



이젠 점점 elasticsearch가 무서워진다~

Posted by 김용환 '김용환'





ansible-playbook 커맨드를 실행하기 전에 플레이북을 확인할 수 있는 플래그가 있다.


1. 문법 체크


--syntax-check 플래그는 플레이북 문법이 유효한지 확인하지만 실행하지 않는다.


$ ansible-playbook --syntax-check playbook.yml





2. 호스트 나열하기


--list-hosts 플래그는 플레이북이 실행될 호스트를 출력하지만 플레이북을 실행하지 않는다.


$ ansible-playbook --list-hosts playbook.yml






3. 태스크 나열하기 


--list-tasks 플래그는 플레이북이 실행될 태스크를 출력하지만 플레이북을 실행하지 않는다.


$ ansible-playbook --list-tasks playbook.yml






4. 체크 모드


-C 플래그와 --check 플래그는 앤서블을 체크 모드를 실행한다(때때로 드라이 런(dry-run)이라 한다) 


즉 플레이북의 각 태스크가 호스트 수정 여부를 알려주지만 서버에 어떠한 변경이 발생하지 않는다.



$ ansible-playbook -C playbook.yml

$ ansible-playbook --check playbook.yml



체크 모드를 사용할  때의 어려움 중 하나는 플레이북의 처음 부분이 실행될 때만 플레이북의 뒷 부분이 성공할 수 있다는 점이다.





5. diff (파일 변경을 표시한다)

-D 플래그와 -diff 플래그는 원격 머신에서 변경된 모든 파일의 출력 비교 정보를 표시한다. 


정상적으로 실행되었다면 앤서블이 파일을 변경하는 방법을 표시하기 위해 -D 플래그와 -diff 플래그를 --check와 함께 사용하면 도움이 된다.


$ ansible-playbook -D --check playbook.yml

$ ansible-playbook --diff --check playbook.yml



앤서블이 파일(예시: copy, template, lineinfile과 같은 모듈을 사용)을 수정하면 다음처럼 .diff 포맷의 변경 사항을 표시한다.


-loglevel = "error"

+loglevel = "warning"





Posted by 김용환 '김용환'



앤서블에서 실행할 태스크를 제어할 수 있다.


가끔 앤서블이 플레이북의 모든 태스크를 실행하는 것을 원치 않을 수 있다. 


특히 플레이북을 처음 작성하고 디버깅할 때 더욱 그렇다. 앤서블은 실행할 태스크를 제어할 수 있는 커맨드 라인 옵션을 제공한다.




1) step


--step 플래그는 다음처럼 각 태스크를 실행하기 전에 앤서블 프롬프트를 표시한다.


Perform task: install packages (y/n/c):


태스크를 실행하거나(y) 건너 뛰거나(n) 프롬프트를 표시하지 않고 나머지 플레이북을 계속 실행하도록 앤서블에 알릴 수 있다(c).


$ ansible-playbook --step playbook.yml






2) start-at-task



--start-at-task <태스크 이름> 플래그는 처음부터가 아닌 지정된 태스크에서 플레이북을 실행하기 시작하도록 앤서블에 알려준다. 


태스크 중 하나에 버그가 있어서 태스크 중 하나가 실패해서 실패한 태스크를 수정해 해당 태스크부터 시작해 플레이북을 다시 실행하고 싶을 때 유용할 수 있다.



$ ansible-playbook --start-at-task="install packages" playbook.yml




3) tags



앤서블에서는 하나 이상의 태그를 태스크 또는 플레이에 추가할 수 있다. 예를 들어 foo라는 태그가 붙은 플레이와 bar와 quux라는 태그가 붙은 플레이가 있다.



- hosts: myservers

  tags:

   - foo

  tasks:

   - name: install editors

     apt: name={{ item }}

     with_items:

       - vim

       - emacs

       - nano


   - name: run arbitrary command

     command: /opt/myprog

     tags:

       - bar

       - quux





-t <태그 이름> 플래그와 --tags <태그 이름> 플래그를 사용해 특정 태그를 포함한 플레이와 태스크만 실행하도록 앤서블에 알린다. --skip-tags <태그 이름> 플래그를 사용해 앤서블에 특정 태그를 포함한 플레이와 태스크를 건너 뛰라고 알린다.



태그를 실행하거나 건너뛰기

$ ansible-playbook -t foo,bar playbook.yml

$ ansible-playbook --tags=foo,bar playbook.yml

$ ansible-playbook --skip-tags=baz,quux playbook.yml


Posted by 김용환 '김용환'



프로그래머 열정을 말하다 책을 봤다. 너무 재미있었다.

http://www.yes24.com/Product/Goods/6185848



원서는 My Job Went to India: 52 Ways to Save Your Job (Pragmatic Programmers)  이다. 

https://www.amazon.com/Job-Went-India-Pragmatic-Programmers/dp/0976694018  (2005년에 쓰여진 책이라니!!)





44살의 개발자 아저씨가 보기에 정말 중요한 내용인 것 같다. 다 완벽하고 좋은 말은 아니지만...


개발을 계속 하고 싶고, 프로그래밍하는 것이 즐겁다면 꼭 보면 좋을 것 같다.




책 내용을 간결히 요약한 블로그가 있으니. 참고하길 바란다.


http://jehyunpark.github.io/book/2017/02/12/the-passionate-programmer.html



Posted by 김용환 '김용환'


클라우드 시스템을 관리하는 기술(http://www.hanbit.co.kr/store/books/look.php?p_code=B9686521083)에서 발췌한 자료이다.



Site Reliability 관행

1. 개발자(coder)만 고용한다.

2. 서비스마다 SLA를 둔다.

3. 성능을 측정하고 SLA를 만족하지 못하는 사항을 보고한다.

4. 오류 계산을 활용하고 개시(lauch)들이 반드시 오류 예산을 지키게 한다.

5. 공통의 직원 풀에서 SRE팀과 개발팀에 인원을 공급한다.

6. 여분의 (운영팀의 수용 능력을 넘는) 운영 (OPS) 작업은 개발팀(DEV)로 흘러가게 한다.

7. SRE 운영 부하가 50%를 넘지 않게 한다.

8. 운영팀의 작업의 5%를 개발팀과 공유한다.

9. 호출대기 팀은 한 장소에 적어도 여덟 명으로 구성하거나 여러 장소들 각각에 적어도 여섯 명으로 구성한다.

10. 호출 대기의 한 교대 근무(shift) 기간에 발생하는 사건이 최대 2회를 넘지 않도록 한다.

11. 모든 사건에 대해 사후 분석(postmortem)을 수행한다.

12. 사후 분석이 누군가를 비난하는 기회가 되어서는 안된다. 사람보다는 공정과 기술에 초점을 두어야 한다.


Posted by 김용환 '김용환'