image

Acesse bootcamps ilimitados e +650 cursos

33
%OFF

JS

Jean Santana10/01/2026 13:03
Compartilhe

Jupyter Notebook + Linux Bash

    Jupyter Notebook

    O Jupyter Notebook (Jupyter Lab, Colab, etc.) já é uma ferramenta consolidada para executar código Python, principalmente no tratamento de dados.

    Porém, além de executar scripts Python, é possível executar códigos e scripts de várias outras linguagens. O nome Jupyter vem de JUlia PYThon E (and ou &) R.

    Conceitualmente, é possível executar qualquer código desde que existe um interpretador de executar o código fornecido.

    Para isso, “basta” instalar ou criar um kernel para o Jupyter que se comunique com o interpretador.

    Por exemplo, o Java possui um REPL que funciona como interpretador, chamado JShell. Com o kernel do JShell, é possível executar Java dentro de um notebook.

    Jupyter + Bash

    É aí que entra a dupla Jupyter + Bash. Isso mesmo: é possível executar código Bash do Linux dentro de um notebook. O melhor é que já existe um kernel pronto para o Jupyter executar comandos Bash.

    E qual a necessidade de executar bash dentro de um notebook?

    Se você vai aprender ou ensinar Bash, essa dupla pode facilitar muito as coisas. Similar ao que acontece em Python, o uso de um Notebook com Bash permite manter em um só lugar a documentação e histórico de execução do seu código.

    É mais fácil planejar, organizar, compartilhar e executar o conteúdo a ser estudado. Em seguida, basta exportar o histórico da execução como arquivo “.html”.

    Pronto, você já tem um documento com código e resultado de tudo que foi feito.

    image

    image

    Estude além do Bash

    Além de organizar estudos sobre Bash, é possível organizar qualquer (ou quase) estudo executado pela linha de comando do Linux.

    Por exemplo, esses dias estou me aventurando a executar Spark em cluster Kubernetes. Porém, estou usando Kubernetes localmente em containers Docker. Ou seja, nem sempre as coisas dão certo.

    Mesmo com ajuda da IA, em determinado momento ficou confuso quais “passos” deram certo ou errado, e manter todo o histórico de saída de comandos não é nada fácil.

    Fazer isso em um Notebook facilita manter um histórico de tudo que foi feito, inclusive o que deu errado (o que é muito importante no processo de aprendizagem).

    Depois, é só criar uma cópia com as execuções que deram certo como documento final.

    image

    Como testar

    Você precisa ter uma distribuição Linux para testar.

    Para usuário Windows, você vai precisar do WSL. Tentei criar, junto com Claude.ai, um kernel para executar o Bash do Git instalado no Windows, mas não obtive muito sucesso. Então, fica com o WSL mesmo.

    No meu teste, usei WSL2/Ubuntu.

    Uma boa prática é criar uma venv para instalar o Jupyter. Considerando que já tenha o Python instalado, basta seguir os procedimentos abaixo.

    # Criação e ativação do ambiente virtual
    user@host:~$ python3 -m venv jupyter_env
    
    user@host:~$ source jupyter_env/bin/activate
    
    # Instalar Jupyter e Bash Kernel
    (jupyter_env) user@host:~$ pip install jupyter
    
    (jupyter_env) user@host:~$ pip install bash_kernel
    Collecting bash_kernel
    Baixando bash_kernel-0.10.0-py2.py3-none-any.whl.metadata (5,2.2 kB)
    Requirement already satisfied: pexpect>=4.0 in ./jupyter_env/lib/python3.12/site-packages (from bash_kernel) (4.9.0)
    Requirement already satisfied: ipykernel in ./jupyter_env/lib/python3.12/site-packages (from bash_kernel) (7.1.0)
    Coletando tipo de arquivo (do bash_kernel)
    Downloading filetype-1.2.0-py2.py3-none-any.whl.metadata (6.5 kB)
    
    # Configurar e listar o kernel
    (jupyter_env) user@host:~$ python -m bash_kernel.install
    Instalando a especificação do kernel IPython
    
    (jupyter_env) user@host:~$ jupyter kernelspec list
    Kernels disponíveis:
    python3 /home/jpierre/jupyter_env/share/jupyter/kernels/python3
    bash /home/jpierre/.local/share/jupyter/kernels/bash
    
    
    # Iniciar o Jupyter Lab
    (jupyter_env) user@host:~$ jupyter lab
    [I 2026-01-10 08:44:17.727 ServerApp] jupyter_lsp | extensão vinculada com sucesso.
    [I 2026-01-10 08:44:17.729 ServerApp] jupyter_server_terminals | extension foi vinculada com sucesso.
    ...
    [I 2026-01-10 08:44:17.933 ServerApp] Jupyter Server 2.17.0 está em execução em:
    [I 2026-01-10 08:44:17.933 ServerApp] http://localhost:8888/lab?token=a952aa75128a49953e51704af476093c3e0597c605101b76
    [I 2026-01-10 08:44:17.933 ServerApp] http://127.0.0.1:8888/lab?token=a952aa75128a49953e51704af476093c3e0597c605101b76
    [I 2026-01-10 08:44:17.933 ServerApp] Use Control-C para interromper este servidor e desligar todos os kernels (duas vezes para pular a confirmação).
    

    Cuidado com conflitos

    Aqui, precisamos fazer algumas considerações. Quando o Jupyter é iniciado, é criado um servidor local acessível no endereço localhost, porta 8888.

    Se você executar mais de uma instância do Jupyter simultaneamente, o próximo servidor estará disponível automaticamente na porta 8889 e assim sucessivamente.

    Se você executar uma instância do Jupyter no Windows e outra no WSL/Ubuntu (ou vice-versa), a segunda instância não “saberá” da primeira, pois cada sistema operacional usa uma instalação distinta do Jupyter.

    Nesses casos, será necessário indicar explicitamente em qual porta o Jupyter deve ser iniciado.

    # Iniciar o Jupyter Lab em uma porta específica
    (jupyter_env) user@host:~$ jupyter lab —ip=0.0.0.0 —port=18888 —no-browser
    

    Também é possível configurar o Jupyter para sempre executar em uma porta específica, como a 18888, por exemplo.

    # Configura porta padrão do Jupyter
    (jupyter_env) user@host:~$ jupyter notebook —generate-config
    
    # Editar arquivo, pressiona CTRL + X ao terminar
    (jupyter_env) user@host:~$ nano ~/.jupyter/jupyter_notebook_config.py
    
    
    # Adicionar o trecho abaixo no final do arquivo
    
    ## Configuração para acesso de qualquer lugar (IP)
    c.NotebookApp.ip = '0.0.0.0'
    
    ## Configuração da porta desejada
    c.NotebookApp.port = 18888
    
    ## Impedir que o Jupyter abra o navegador automaticamente
    c.NotebookApp.open_browser = False
    c.ServerApp.open_browser = False
    

    Limitações

    Algumas limitações que encontrei na solução

    • Não consegui executar programas que precisam de interação dentro do programa, como o nano, por exemplo. Para sair do nano, é necessário passar o comando CTRL+x;
    • A função autocompletar com a tecla “Tab” não funciona para nomes de diretórios e arquivos;
    • Não consegui executar dois notebooks simultaneamente usando o kernel do Bash

    Bônus

    Se você estiver executando o Jupyter em um navegador com IA, como o Comet, por exemplo, pode fazer perguntas sobre a página como fonte de informação.

    image

    Resuma o conteúdo dessa página

    O notebook mostra comandos para inspecionar um cluster Kubernetes criado com Kind, rodando em um ambiente Debian/WSL2, com um nó de controle e quatro nós de trabalho, todos prontos e sem pressões de recurso aparentes.​

    Comandos executados

    • Tentativa de usar o comando kind para listar clusters, mas o binário não está instalado ou não está no PATH, gerando mensagem “Command 'kind' not found”.​
    • Uso de kubectl get nodes para listar os nós do cluster, exibindo um nó desktop-control-plane e quatro nós desktop-worker em status Ready com versão v1.34.2.​
    • Uso de kubectl get pods -n kube-system para verificar pods de sistema, como coredns, kube-apiserver, kube-scheduler, kube-controller-manager, kube-proxy, kindnet e etcd, todos em estado Running.​

    Versão do cluster

    • Comando kubectl version mostrando cliente na versão v1.34.1 com Kustomize v5.7.1.​
    • Servidor Kubernetes reportado na versão v1.34.2.​

    Detalhes dos nodes

    • kubectl describe nodes exibe, para cada nó, informações de capacidade (16 CPUs, ~16 GiB de memória, 110 pods por nó), sistema operacional Debian GNU/Linux 12, runtime containerd://2.2.0 e kernel 6.6.87.2-microsoft-standard-WSL2.​
    • As condições de todos os nós indicam MemoryPressure=False, DiskPressure=False, PIDPressure=False e Ready=True, sem eventos de erro relevantes, apenas eventos normais de registro de nó.​

    Pods e recursos alocados

    • Para o nó de controle, os pods principais são coredns, etcd, kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy, kindnet e local-path-provisioner, com solicitações de recurso baixas (menos de 5% de CPU e cerca de 1–2% de memória).​
    • Nos nós de trabalho aparecem pods de rede (kindnet), kube-proxy e alguns workloads adicionais como spark-operator e portainer-agent, todos sem limites nem requests agressivos, mantendo uso de recursos muito baixo.​
    Compartilhe
    Recomendados para você
    Microsoft Certification Challenge #5 - AI 102
    Bradesco - GenAI & Dados
    GitHub Copilot - Código na Prática
    Comentários (0)