# using vim inside any container without installing it

### Who is this tutorial for?

The beauty of **docker** is that everybody can use it, specially developers. But in my [English Classes](https://oteacher.org/teachers/shakibamoshiri) all those senior developers said "We are familiar with docker". Even a PM mentioned he was familiar with **Kubernetes**! :| So I asked myself what is the difference between me (as an SRE) with developers using docker. This is a tiny sample of the answer.

{% hint style="danger" %}
NOTICE

This tutorial is for

* having fun
* learning purposes

**do not use it on production.**
{% endhint %}

### What is wrong with installing X in my container?

When we need a text editor inside our container, the first idea (or a question) comes in to mind is why this container does not have vim? And then ohhh I have to install it.

So if we add **vim** to a container, we added a file which we do not need it so often. and we increased the size of that container just because of an edit per a week or month! And I do not go further with security issues.

So not just vim, we should not treat a **container** like a **VM** and `exec` to it and install some apps. if you are a **developer** that is OK but if you are an **SRE** THAT IS NOT OK!

### The developers way

Just running `docker container exec -it [name|ID] shell-to-login` and then depending on the OS type using `apt install` or `yum install` or etc. Doing whatever we needed, exiting the container; while it is running we have it, after removing it, it is gone (vim is gone)

The next time? again `... exec ...` in that container `... install ...` it and after a while it is gone!

### The SREs way

#### Finding the vim executable path

```bash
which vim
/usr/bin/vim
```

Check it it is executable or no a symbolic link, we should fine the main executable file

```
file `which vim`
/usr/bin/vim: symbolic link to /etc/alternatives/vim

# one more time
file /etc/alternatives/vim
/etc/alternatives/vim: symbolic link to /usr/bin/vim.basic

# one more time
file /usr/bin/vim.basic
/usr/bin/vim.basic: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=212ed02d8d1e7d300881fea8b903e0dc9abdd353, stripped
```

Okay, we found executable file at `/usr/bin/`

#### Finding dynamic libraries for vim using `ldd` command

```
ldd `which vim`
	linux-vdso.so.1 (0x00007ffd265dd000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f86429ef000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f86427c5000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f864259d000)
	libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f8642395000)
	libgpm.so.2 => /usr/lib/x86_64-linux-gnu/libgpm.so.2 (0x00007f864218f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8641f8b000)
	libpython3.6m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0 (0x00007f86418e0000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f86416c1000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f86412d0000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8643227000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f864105e000)
	libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f8640e59000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f8640c27000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8640a0a000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f8640807000)
```

#### Finding directory paths for those shared libraries

```
ldd `which vim` | perl -lne '/\/[^ ]+/ && print $&' | xargs -I xxx dirname xxx | sort | uniq
/lib64
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
```

so far we have `vim` path and shared libraries paths 

```
/usr/bin
/lib64
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
```

Other paths we need are

```
# vim shared files
/usr/share/vim

# vim config directory
/home/$USER/.vim
```

So we have 5 paths to be **mounted** in to our container to have access to vim inside the container without installing it. YES we use our host's vim and its dependencies.

#### Running nginx:alpine which does not have vim by default

If you do not have `nginx:alpine` you can use `docker/getting-started` container instead.

```
docker pull docker/getting-started
```

#### Mounting vim inside our container

```
docker container run --rm -it -p 80:80 \
    --name getting_started \
    -v /lib64:/lib64 \
    -v /lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu \
    -v /usr/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu \
    -v /usr/bin:/usr/bin \
    -v /home/shu/.vimrc:/root/.vimrc \
    -v /home/shu/.vim:/root/.vim  \
    -v /usr/share/vim:/usr/share/vim \
    docker/getting-started
```

#### Testing it

```
docker exec -it getting_started sh 
```

Open a file with vim inside our container

```
/usr/bin/vim.basic /root/.vimrc
```

#### Screenshot of docker run

![](/files/69k7wefAuv2yUN9eCOuq)

#### Screenshot of vim

![](/files/T8nj2TIrO4NdWNmq17X4)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.shakiba.net/container/docker/using-vim-inside-any-container-without-installing-it.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.