Perbedaan antara Docker, containerd, CRI-O dan runc

Sedikit berbagi sumber informasi tentang pemahaman thema yang saya sebut di judul atas.

Sumber Informasi asli saya dapatkan di sini: https://www.kreyman.de/index.php/others/linux-kubernetes/232-unterschiede-zwischen-docker-containerd-cri-o-und-runc

Munculnya Docker memicu ledakan popularitas kontainer. Sejak itu, semakin banyak alat dan standar yang dirancang untuk membantu mengatur penggunaan teknologi ini.

Sayangnya, cukup sulit untuk mengikuti perkembangan. “Pertempuran” antara perusahaan teknologi besar juga membingungkan bagi banyak dari kita.

Dalam artikel ini, saya akan membahas semua nama besar yang pernah Anda dengar dan mencoba menguraikan jargon teknis untuk Anda dan menjelaskan bagaimana ekosistem kontainer akan bekerja sama pada tahun 2021.

Dan jika Anda berpikir bahwa Anda adalah satu-satunya yang tidak mengerti semua ini, jangan khawatir … Anda tidak sendirian!

Pahami Docker

Ada perbedaan antara Docker (dalam bentuk perusahaan), Docker-Containern, Docker-Images, dan Development Tools Docker yang biasa kita gunakan:

Joe Beda Twitter

Sumber:  https://twitter.com/jbeda

Seperti yang Anda lihat, Anda bukan satu-satunya yang bingung. Joe Beda , co-developer Kubernetes, setuju.

Ini adalah kesempatan sempurna untuk menjernihkan beberapa kebingungan dan membantu Anda memahami kapan itu Docker, containerd, atau CRI-O. Ini sangat penting jika Anda ingin membahas topik Kubernetes.

Penting bagi Anda untuk mengingat hal-hal berikut:

Wadah tidak lagi dikaitkan secara permanen dengan nama Docker. Ada beberapa alat kontainer yang tersedia. Docker adalah salah satunya, dan Docker (perusahaan) mendukung beberapa tetapi tidak semuanya.

Jika Anda masih berpikir bahwa container hanyalah Dockers, baca terus! Sekarang kita akan melihat lebih dekat pada ekosistem kontainer.

Garis besar ekosistem kontainer

Ekosistem kontainer terdiri dari banyak teknologi, istilah khusus, dan perusahaan pesaing. Untungnya, perusahaan terkadang menegosiasikan gencatan senjata yang rapuh untuk menyepakati standar tertentu. 

Standar ini membantu untuk mencapai interoperabilitas antara alat yang berbeda dan menghindari ketergantungan pada perusahaan atau proyek tertentu (teknologi). Standar dasar yang harus diikuti:

  • Container Runtime Interface (CRI) mendefinisikan API antara Kubernetes dan Container Runtime.
  • Open Container Initiative (OCI) mendefinisikan standar untuk image dan container.

Diagram di bawah menunjukkan bagaimana Docker , Kubernetes , CRI , OCI , containerd dan runc cocok bersama dalam ekosistem ini:

Penjelasan Hubungan antara docker, CRI-O, containerd und runc Sumber Informasi: www.tutorialworks.com
  1. Ini adalah alat yang digunakan untuk menjalankan kontainer dalam pengembangan atau produksi.
  2. CRI ( Container Runtime Interface) adalah Kubernetes API (Application Programming Interface). CRI mendefinisikan cara Kubernetes berinteraksi dengan runtime container yang berbeda. Karena standar dalam spesifikasi, Anda dapat memilih implementasi CRI mana yang ingin Anda gunakan atau mungkin Anda tulis sendiri.
  3. Anda dapat memilih sendiri runtime yang sesuai dengan spesifikasi Container Runtime Interface (CRI). containerd dikembangkan oleh Docker. Plug-in CRI adalah plug-in yang terintegrasi secara bawaan dalam containerd dan diaktifkan secara default (dari versi 1.1). Ini memungkinkan Anda untuk menjalankan Kubernetes dengan containerd sebagai runtime container. CRI-O adalah proyek open source dan alternatif untuk containerd dan didukung oleh sejumlah perusahaan terkenal.
  4. OCI adalah spesifikasi standar industri terbuka yang berisi dua spesifikasi: spesifikasi runtime (runtime-spec) dan spesifikasi gambar (image-spec)
  5. runC adalah alat yang sesuai dengan OCI untuk membuat dan menjalankan container. runc digunakan untuk membuat dan menjalankan container sesuai dengan spesifikasi OCI.
sumber info: https://www.kreyman.de/index.php/others/linux-kubernetes/232-unterschiede-zwischen-docker-containerd-cri-o-und-runc

Docker

Kami akan mulai dengan Docker karena ini adalah alat kontainer paling populer saat ini. Bagi banyak orang, nama “Docker” sendiri merupakan sinonim dari kata “container”.

Docker memulai seluruh revolusi containerisasi ini. Docker telah menciptakan alat yang sangat ergonomis dan mudah digunakan untuk bekerja dengan container, yang juga disebut Docker.

Proyek untuk mengoperasikan wadah dengan Docker
Sumber: www.tutorialworks.com


  1. Administrasi dari Pengguna / administrator dan memulai container dengan CLI Docker.
  2. containerd menggunakan image, mengelola jaringan dan penyimpanan, dan menggunakan runc untuk menjalankan container
  3. runc menangani Low Level “Stab” process untuk membuat dan menjalankan proses container 

docker  dapat diinstal pada sistem operasi klien atau pada sistem operasi server. docker  berisi sejumlah alat yang menyederhanakan pekerjaan pengembang dan insinyur DevOps. Dengan  CLI buruh pelabuhan Anda dapat membuat image container, mengambilnya dari repositori, membuat container, memulai dan mengelolanya.

Docker terdiri dari tiga proyek:

docker-cli – adalah utilitas baris perintah yangberinteraksidengan Anda menggunakan perintah docker .

containerd –  adalah daemon Linux yang mengelola dan memulai container. Ini mengunduh gambar dari repositori, mengelola penyimpanan dan jaringan, dan memantau eksekusi kontainer.

Runc – adalah runtime container tingkat rendah yang benar-benar membuat container dan menjalankan. Ini termasuk  libcontainer , implementasi berbasis Go asli untuk membuat container.

Saat Anda menjalankan wadah dengan docker , Anda sebenarnya menjalankannya dari daemon docker, containerd, dan kemudian runc .

Dockershim: Docker di Kubernetes

Penting untuk dicatat bahwa Kubernetes hanya dapat melayani runtime container yang mendukung Container Runtime Interface (CRI). Namun, Docker tidak dapat secara langsung mendukung standar ini. Oleh karena itu, Kubernetes menyertakan komponen yang disebut dockershim, yang diperlukan untuk bekerja dengan Docker.

Di masa mendatang (dari versi 1.23) Kubernetes akan menghentikan dukungan untuk Dockershim dan juga Docker dan hanya akan bekerja dengan Container Runtime s yang mendukung Container Runtime Interface (CRI) – containerd atau CRI-O . ( FAQ Penghentian Dockershim )

Namun, ini tidak berarti bahwa Kubernetes tidak akan dapat menjalankan container berformat Docker. Baik containerd maupun CRI-O dapat menjalankan gambar berformat Docker (berformat OCI). Anda tinggal melakukannya tanpa harus menggunakan perintah docker atau daemon Docker.

Shim – Secara teknis, shim adalah komponen dalam sistem perangkat lunak yang bertindak sebagai jembatan antara berbagai API atau sebagai lapisan kompatibilitas. Terkadang shim ditambahkan saat Anda ingin menggunakan komponen pihak ketiga. Anda membutuhkan sedikit kode lem untuk membuatnya bekerja.

Docker-Images

Apa yang disebut banyak orang sebagai Docker Image sebenarnya adalah Image yang dikemas dalam format Open Container Initiative (OCI) .

Jika Anda ingin mengunduh gambar dari Docker Hub atau repositori lain, Anda dapat melakukannya dengan perintah  buruh pelabuhan atau dengan utilitas podman, atau dengan alat lain yang mendukung spesifikasi format gambar OCI.

Container Runtime Interface (CRI)

CRI adalah API yang digunakan Kubernetes untuk mengontrol berbagai runtime container untuk membuat dan mengelola container.

CRI menyederhanakan penggunaan runtime container yang berbeda untuk Kubernetes (atau lebih tepatnya kubelet ). Alih-alih mendukung setiap kemungkinan runtime container secara terpisah, hanya standar CRI yang didukung yang digunakan. Dalam hal ini, tugas manajemen kontainer sepenuhnya terletak pada runtime kontainer.

Sumber: www.tutorialworks.com

Jadi, jika Anda lebih suka menggunakan containerd untuk menjalankan container Anda, jangan ragu untuk melakukannya. Atau, jika Anda lebih suka menggunakan CRI-O maka Anda dapat menggunakan ini dengan aman. Ini karena spesifikasi CRI diimplementasikan di kedua runtime.

Sebagian besar waktu, jika Anda adalah pengguna akhir, bagaimana Anda mengimplementasikannya tidak menjadi masalah. Implementasi CRI dirancang agar dapat dipasang dan diubah dengan mulus.

Untuk informasi Anda: Red Hat (proyek OpenShift) menggunakan CRI-O dan bertanggung jawab atas pemeliharaannya (keamanan, perbaikan bug, dll.). Sementara containerd terus dibungkus oleh Docker.

Runtime container mana yang digunakan di Kubernetes?

The kubelet (sebuah berjalan agen pada setiap node) bertanggung jawab untuk berinteraksi dengan runtime wadah dalam arsitektur Kubernetes. Tugas utama kubelet adalah mengirimkan instruksi start/stop ke runtime container.

Opsi berikut digunakan untuk mengonfigurasi runtime container:  –container-runtime dan  –container-runtime-endpoint. Anda dapat mengetahui Container Runtime mana yang sudah terinstal di infrastruktur Kubernetes Anda menggunakan rantai perintah berikut:

kubectl mendeskripsikan simpul <node_name>

sumber info: https://www.kreyman.de/index.php/others/linux-kubernetes/232-unterschiede-zwischen-docker-containerd-cri-o-und-runc

containerd

containerd adalah runtime container tingkat tinggi yang berasal dari Docker dan mengimplementasikan spesifikasi CRI. ontainerd menarik gambar dari repositori, mengelolanya dan kemudian meneruskannya ke runtime bawahan, yang benar-benar membuat dan menjalankan proses kontainer.

containerd  telah dihapus dari proyek Docker untuk membuat Docker lebih modular. Jadi Docker menggunakan containerd untuk dirinya sendiri.Saat Anda menginstal Docker, containerd juga   diinstal secara otomatis. Selain itu, ontainerd menggunakan pluginnya sendiri untuk mendukung CRI di Kubernetes.

CRI-O

CRI-O adalah runtime container tingkat tinggi lainnya yang mengimplementasikan Container Runtime Interface (CRI). CRI-O adalah alternatif untuk  containerd dan bekerja dengan cara yang sama.

CRI-O dikembangkan dengan dukungan Red Hat, IBM, Intel dan SUSE sebagai wadah runtime untuk Kubernetes. CRI-O menawarkan kemungkinan untuk memulai, menghentikan, atau memulai ulang container, sama seperti containerd.

Inisiatif Kontainer Terbuka (OCI)

OCI adalah sekelompok perusahaan teknologi yang mempertahankan spesifikasi untuk format gambar kontainer dan eksekusi kontainer.

Gagasan di balik OCI adalah Anda dapat memilih di antara berbagai runtime yang sesuai dengan spesifikasi. Masing-masing runtime ini memiliki sub-implementasi yang berbeda.

Misalnya, Anda memiliki satu runtime yang kompatibel dengan OCI untuk host Linux Anda dan satu untuk host Windows Anda. Ini adalah keuntungan memiliki standar yang dapat diterapkan oleh banyak proyek yang berbeda.

runc

runc  adalah runtime kontainer yang kompatibel dengan OCI. Ini mengimplementasikan spesifikasi OCI dan menjalankan proses container.

runc  disebut sebagai  implementasi referensi  OCI.

Apa itu implementasi referensi?

Implementasi referensi adalah perangkat lunak yang telah mengimplementasikan semua persyaratan spesifikasi atau standar. Biasanya software pertama yang dikembangkan dari spesifikasinya. Dalam kasus OCI, runc menawarkan   semua fungsi yang diharapkan dari runtime yang sesuai dengan OCI, meskipun setiap orang dapat mengimplementasikan runtime OCI mereka sendiri jika mereka mau.

runc  menawarkan semua fungsi tingkat rendah untuk wadah dan berinteraksi dengan fitur Linux tingkat rendah yang ada seperti ruang nama dan grup kontrol. runc menggunakan fungsi-fungsi ini untuk membuat dan menjalankan proses container.

Ada juga beberapa alternatif untuk runc :

  • crun adalah runtime kontainer yang ditulisdalam  C (sebaliknya, runc ada di Go )
  • kata-Runtime berasal dari proyek Katacontainers , yang mengimplementasikan spesifikasi OCI sebagai VM ringan individual (virtualisasi perangkat keras)
  • gVisor berasal dari Google dan dapat membuat wadah dengan kernelnya sendiri. Ini mengimplementasikan OCI dalam runtime-nya yang disebut runc .

Kesimpulan

Dalam artikel ini kita melihat bahwa Docker hanyalah sebagian kecil dari keseluruhan ekosistem container. Ada standar terbuka: CRI dan OCI serta proyek seperti  containerdrunc  dan  CRI-O . Kami akan segera melihat banyak implementasi baru dari runtime container dengan dukungan untuk standar CRI dan OCI.

Semoga artikel ini bisa memberi sedikit pencerahan tentang gelapnya dunia container.

Pengarang: Tom Donohue

Posting blog ini adalah terjemahan dari bahasa Jerman. Anda dapat menemukan artikel asli di tautan ini . (https://www.kreyman.de/index.php/others/linux-kubernetes/232-unterschiede-zwischen-docker-containerd-cri-o-und-runc)

Draw your Diagram with PlantUML

Ref:

PlantUML Syntax:

listsprite

PlantUML Syntax:

help themes

PlantUML Syntax:
!theme spacelab
Alice -> Bob: Authentication Request
Bob --> Alice: Authentication Response

Alice -> Bob: Another authentication Request
Alice <-- Bob: another authentication Response

PlantUML Syntax:
!theme spacelab
actor Foo1
boundary Foo2
control Foo3
entity Foo4
database Foo5
collections Foo6
Foo1 -> Foo2 : To boundary
Foo1 -> Foo3 : To control
Foo1 -> Foo4 : To entity
Foo1 -> Foo5 : To database
Foo1 -> Foo6 : To collections

PlantUML Syntax:
!theme spacelab
!procedure $foo($arg)
  :procedure start;
  !while $arg!=0
    !$i=3
    #palegreen:arg=$arg;
    !while $i!=0
      :arg=$arg and i=$i;
      !$i = $i - 1
    !endwhile
    !$arg = $arg - 1
  !endwhile
  :procedure end;
!endprocedure

start
$foo(2)
end

some not working plantuml_map in worldpress

PlantUML Syntax:

!theme spacelab
Customer - (Perform checkout)
(Perform checkout) ..> (Payment) : include
(Perform checkout) ..> (Get help): extends
(Perform checkout) - Clerk

PlantUML Syntax:

!theme spacelab
@startuml
[Bitbucket] as Bitbucket 
!theme spacelab
package Bitbucket { 
	component app1 src2 --> app2 src3 --> app3 src4 --> app4 src5 --> app5 src6 --> app6 src7 --> app7 src10 --> app8 src9 --> st src9 --> it src8 --> jks src11 --> db st <-- robot st --> st_report it <-- pabot it --> it_report jks --> rf_runner jks --> rebot rf_runner --> robot rf_runner --> pabot st_report --> rebot it_report --> rebot @enduml " usemap="#plantuml_map">

Nikon System

Hampir sebagian besar dari foto yang selama ini saya hasilkan, merupakan hasil dengan nikon system . Kalau anda bertanya mengapa saya memakai system ini tidak system yang lain, alasan saya adalah karena saya terlanjur memilih system ini seperti yang anda ketahui, semangkin lama seseorang menggunakan sebuah system semangkin sulit untuk merubah system yang anda pakai.

Sejalan dengan waktu (hampir kira-kira 20 tahun mengenal hobby fotografi), sekarang saya menggunakan system nikon dengan lensa mulai dari 15mm-500mm, dengan berapa body Analog & Digital (FF / APS)

Secara keseluruhan gambaran system yang saya pergunakan:

Body Analog:

  • nikon F4
  • nikon F3 Pinslide
  • nikon F801
  • nikon FM2n
  • nikon FG20

Body Digital:

  • nikon D50 (APS)
  • nikon D850 (FF)
  • nikon D500 (APS)

Lensa:

  • Zeiss Distagon 15mm/2.8 ZF2
  • nikkor AF 20mm/2.8
  • Samyang TS 24mm f3.5 ED AS
  • Mamiya-Sekor 35mm/3.5 N , Zorkendorf PC
  • nikkor AF 35mm/2.0D
  • Voigländer Ultron 40mm/2.0 SL
  • nikkor 50mm /1.8 AiS
  • Olympus Zuiko Macro Auto 50mm f3.5 dengan olympus OM – Nikon F adapter
  • Olympus Zuiko Macro Auto1:1 85mm f4 dengan olympus OM – Nikon F adapter
  • nikkor AF 85mm/1.8
  • nikkor 85mm/2.0 AiS
  • nikkor AF macro 105mm/2.8
  • EL APO Nikkor 135mm/5.6
  • nikkor 400mm/3.5 AIS
  • nikkor 500mm/4.0 P
  • nikkor AFD 80-200mm/2.8
  • zoom nikkor 35-105mm/3.5-4.5 AI-S
  • nikkor AFS 17-55mm/2.8

Telekonverter:

  • TC 14B
  • TC 301

Assesorie:

  • Blitz SB 24, SB15, SB700
  • SD 7 Blitz powerpack
  • SU 4 Blitzsensor
  • SK17 TTL blitzkabel
  • Kenko makro tube (modifikasi)
  • PB4 (modifikasi) dengan lensa EL APO Nikkor 135mm/5,6 & PS4
  • Zorkendorf PC adapter dengan lensa Mamiya 35mm/3,5 sebagai PC lensa
  • Berbagai Adapter dan Filter

Bersamaan dengan waktu berjalan, cuma lensa nikkor AFD 80-200mm/2,8 (D850) & nikkor AFS 17-55mm/2.8 (D50/D500) sebagai lensa zoom yang masih saya pakai, selebihnya saya lebih suka untuk memakai lensa fix lens ( terutama 35mm, 85mm & 20mm), kalau saya hanya bisa membawa 1 lensa maka saya memilih untuk keluar dengan lensa 40mm.

Using Olympus Zuiko OM Macro Lens on Nikon DSR Camera

Dalam artikel ini saya mencoba untuk menjabarkan mengapa saya menggunakan lensa olympus macro untuk membuat slide copy dengan nikon DSR kamera saya.

Seiring dari migrasi PC saya dari windows XP ke MAC, saya menemui hal yang agak mengganggu dalam kegiatan fotografi saya, sebelum berpindah ke MAC semua slide Analog saya selalu saya digitalisasi dengan Film Scanner (Canon Canoscan 2700) , scanner ini mesih menggunakan SCSI2 interface untuk dihubungkan dengan PC, setelah migrasi ke MAC , ternyata sangat sulit untuk mencari Driver serta Adapter untuk menghubungkan USB ke SCSI2, karena itu saya mencari solusi bagaimana mendigitalisasi film atau slide saya.

Beberapa waktu yang lalu saya temukan solusi yang menarik untuk digitalisasi Slide dan Negativ saya dengan Lensa Macro (Olympus OM Zuiko Auto Macro 50mm/F3.5 ).

Transfer Slide to digital with Nikon PB4 and PS4 on D850 & Zuiko 50mm Macro lens

Adalah sangat mudah dan nyaman untuk mengatur focus lensa secara manual, dengan Live view mode dengan D850. Waktu digitalisasi juga sangat cepat dibandingkan dengan menggunakan film scanner.

Berikut ini lensa Olympus Zuiko OM yang saya gunakan:

  • Olympus Zuiko Macro Auto 50mm f3.5
  • Olympus Zuiko Macro Auto 1:1 85mm f4
  • Olympus Zuiko MC Auto-Macro 135 mm f4.5

ini adalah adapter yang saya gunakan:

  • Olympus OM – Nikon F Adapter

T2 adapter with dandelion chip

ini adalah modifikasi yang terakhir saya lakukan untuk menggunakan Exa Bellow Tessar 50mm/f2,8 saya dengan Zörk Mini Macro

Pada dasarnya Zörk Mini Macro bisa diadaptasikan ke semua kamera bajonet dengan T2 Mount, karena itu saya mengadaptasikan T-mount adapter saya dengan menambahkan dandelion chips sehingga dapat menggunakan langsung lensa Tersebut di Body Kamera Nikon untuk pemotretan Macro.

Zörk Mini Macro: (nikon F – M39)

Perbandingan Mini Macro adapter dengan dan tanpa chips (di kiri dengan, di kanan tanpa):

Lensa: M42 Exa Bellow Tessar 50mm/f2,8 Jena DDR

Komponen yang dipakai (dari kiri ke kanan):

  • T2 adapter nikon F dengan dandelion chip
  • Zoerk Mini Makro Tubus dengan T2
  • M42 Tube
  • Lensa Tessar Below (Sunk Tessar) 50mm F2,8 , Carl Zeiss Jena DDR (M42), Rana dari F2,8 -F22, bisanya saya gunakan dengan rana 5,6 atau 8 untuk pemotretan macro dengan (D50/ D850)

Exif info di Nikon NX Studio:

Exif infos from Dandelion Chips

Contoh hasil foto dengan Nikon D850 :

contoh hasil foto dengan Nikon D50:

(c) Andie Tanadi

Installing RIDE on Rasbian 64 OS

prepare wxpython installation:

sudo apt update
sudo apt -y build-essential
sudo apt-get install libgtk-3-dev

Install wxpython for build on Pi:

sudo pip3 install -U wxpython

Remark this process can take hours for buiding installer!

Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Collecting wxpython
  Using cached https://files.pythonhosted.org/packages/b0/4d/80d65c37ee60a479d338d27a2895fb15bbba27a3e6bb5b6d72bb28246e99/wxPython-4.1.1.tar.gz
Requirement already satisfied, skipping upgrade: pillow in /usr/lib/python3/dist-packages (from wxpython) (5.4.1)
Requirement already satisfied, skipping upgrade: six in /usr/lib/python3/dist-packages (from wxpython) (1.12.0)
Requirement already satisfied, skipping upgrade: numpy in /usr/lib/python3/dist-packages (from wxpython) (1.16.2)
Building wheels for collected packages: wxpython
  Running setup.py bdist_wheel for wxpython ... done
  Stored in directory: /home/andie/.cache/pip/wheels/54/32/da/dc5c828a12bc9a1ca58d5555f1076fd7d2984ae9c0e03eb510
Successfully built wxpython
Installing collected packages: wxpython
  The scripts helpviewer, img2png, img2py, img2xpm, pycrust, pyshell, pyslices, pyslicesshell, pywxrc, wxdemo, wxdocs and wxget are installed in '/home/andie/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed wxpython-4.1.1

Install RIDE:

sudo pip3 install robotframework-ride

now you can start it via terminal:

nohup ride.py &

Migrasi Pi OS dari SD card ke M2-SSD pada Pi 4 8G

seiring dengan keluarnya Raspberry pi4 8G , saya memigrasikan seluruh sistim development saya ke Raspbian 64 OS,

ini adalah hardware yang saya gunakan:

  • Raspberry Pi 4 Computer Modell B, 8GB RAM
  • Argon ONE M.2 Case für Raspberry Pi 4
  • Kingston M.2 SSD A400 240GB
  • Raspberry Pi USB-C Netzteil 5,1V / 3,0A, EU

Alasan saya memigrasikan dari SD card 64G ke SSD 240 adalah karena kebutuhan tempat untuk code saya, juga kecepatan boot dan operasi dari Pi yang saya pergunakan.

Referensi info untuk migrasi bisa anda lihat dengan detail di sini:

Allow user agent on local/client host to ssh remote server without a password.

  1. Create Authentication SSH-Keygen Keys on client: ssh-keygen -t rsa
  2. Create .ssh Directory on the remote server: ssh user@192.168.XXX.XXX mkdir -p .ssh
  3. Upload Generated Public Keys to remote server: cat ~/user/.ssh/id_rsa.pub | ssh user@192.168.XXX.XXX ‘cat >> .ssh/authorized_keys’
  4. Set Permissions on remote server: ssh user@192.168.XXX.XXX “chmod 700 .ssh; chmod 640 .ssh/authorized_keys”
  5. Test passwordless ssh connection: ssh user@192.168.XXX.XXX

Vintage Lens 2 on Nikon DSLR

Lensa macro kedua yang menarik yang saya pergunakan untuk makro fotografi dengan kamera DSLR, adalah Olympus Zuiko Macro Auto1:1 85mm f4.

Olympus sebagai produsen Fotografi optik juga terkenal, dengan Produk (lensa macro) yang mempunyai kwalitas yang sangat baik , lensa ini menarik untuk saya karena jarak ke motiv yang sangat nyaman untuk pemotretan, dan kalau digunakan langsung dengan nikon D50 & Dandelion Chip Tube saya (22mm). saya dapat menggunakan on Body Flash untuk pemotretan macro saya.

Lensa: Olympus OM Zuiko 1:1 Macro Lens 80 mm f/4

Assesori: Adapter Lensa Olympus OM ke Nikon F MountDandelion chipping Tube.

Contoh hasil foto dengan D50 & D850