Comment utiliser Next.js avec Docker et Docker Compose

Dans ce tutoriel, nous allons apprendre à utiliser Next.js avec Docker et Docker Compose pour les débutants.

Avant de vous lancer dans le code, voici quelques prérequis :

  • Vous devriez avoir Node.js installé sur votre système, de préférence le dernier LTS qui est Node.js v 18 au moment de la rédaction. De même, une certaine connaissance de npm et npx sera également nécessaire.
  • Avoir Docker installé et docker-compose installé sur votre machine
  • Toute expérience préalable avec Next.js est bénéfique mais pas nécessaire.

Dans la section suivante, vous installerez Next.js sans Docker, puis Dockerize.

Installer Next.js sans Docker

Pour ce didacticiel, vous utiliserez l'exemple API Routes des exemples officiels Next.js. Vous pouvez installer cet exemple en exécutant :

npx create-next-app --example api-routes api-routes-app

Il affichera une sortie comme celle ci-dessous :

Next.js crée l'application suivante avec la commande CLI de l'exemple d'itinéraires d'API

Pour tester si l'exemple fonctionne correctement, vous pouvez exécuter :

cd api-routes-app
npm run dev

Il exécutera le serveur et vous pourrez maintenant accéder à l'application à l'adresse http://locahost:3000 qui ressemblera à ceci :

Next.js exécuté localement sans Docker

Vous pouvez cliquer sur les noms et jouer. Dans la section suivante, vous allez dockeriser cet exemple d'application Next.js qui a des API pour les personnes.

Image Docker pour Next.js

Pour Dockeriser l'application ci-dessus, vous allez ajouter le Dockerfile suivant à la racine du projet :

FROM node:18-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app

COPY package.json package-lock.json ./
RUN  npm install --production

FROM node:18-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

ENV NEXT_TELEMETRY_DISABLED 1

RUN npm run build

FROM node:18-alpine AS runner
WORKDIR /app

ENV NODE_ENV production
ENV NEXT_TELEMETRY_DISABLED 1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder --chown=nextjs:nodejs /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json

USER nextjs

EXPOSE 3000

ENV PORT 3000

CMD ["npm", "start"]

Il s'agit d'un Dockerfile en plusieurs étapes qui commence par une étape deps . Dans cette première étape qui part de l'image Alpine de Node.js. Ensuite, il ajoute le package lib6-comat nécessaire pour construire Next.js. Comme l'étape s'appelle deps pour les dépendances, à cette étape, les modules npm sont ensuite installés.

Après cela, vous ajoutez l' étape du générateur où les modules de nœud sont copiés et la commande npm run build est exécutée pour générer le projet Next.js. Vous désactivez également la télémétrie Next.js, ce qui accélère un peu la construction.

Après cela, vous définissez l' étape du coureur . Il s'agit de l'étape principale qui exécute Next.js. Ici, vous utilisez l'image Alpine Node.js 18 similaire à toutes les étapes ci-dessus. Ajoutez ensuite un groupe et un utilisateur pour Next.js. C'est aussi important pour la sécurité. Après cela, vous copiez le dossier suivant à partir de l' étape du générateur , ainsi que les modules de nœud et le fichier package.json. Ensuite, vous définissez l'utilisateur comme étant nextjs qui exécutera la commande pour exécuter le projet Next.js. À la fin, vous exécutez npm start qui démarrera le conteneur avec cette commande.

Ajout de Docker compose pour Next.js

Vous pouvez exécuter Next.js avec uniquement le fichier Docker ci-dessus, mais ce sera une longue commande. Pour garder les choses simples, vous allez introduire un nouveau fichier docker-compose.yml avec le contenu suivant à la racine du projet :

version: '3.8'
services:
  web:
    build:
      context: ./
      target: runner
    volumes:
      - .:/app
    command: npm run dev
    ports:
      - "3000:3000"
    environment:
      NODE_ENV: development

Ici, vous définissez un service appelé web et l'étape/la cible à exécuter . Vous liez le répertoire local à /app sur le conteneur, cela facilitera le rechargement à chaud sur le développement local car les fichiers seront écrasés localement à chaque sauvegarde.

Ensuite, vous remplacez la commande par npm run dev et reliez le port local 3000 au port de conteneur 3000. Enfin, vous définissez le NODE_ENV sur development .

Le détail le plus important dont vous devez vous souvenir ici est que le fichier Docker ci-dessus est prêt pour la production et Docker compose dans ce cas est conçu pour être utilisé uniquement pour le développement.

Exécutez Next.js avec docker compose

Pour exécuter le projet Next.js avec docker-compose, vous allez créer l'image Docker, puis exécuter le conteneur. Pour ce faire, vous exécuterez :

COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build

Vous demandez à docker d'utiliser Buildkit, ce qui accélérera le processus de construction de docker. La commande, si elle est exécutée avec succès, se terminera comme suit :

Next.js Docker construit avec le kit de composition et de construction Docker

Pour exécuter Next.js avec Docker et docker-compose, vous pouvez alors exécuter :

docker-compose up

Il affichera le même résultat que l'exécution de l'application sans docker lorsque vous appuyez sur http://localhost:3000 sur votre navigateur préféré après que docker-compose s'exécute sans aucune erreur :

Next.js exécuté localement avec Docker

Si vous modifiez pages/index.tsx pour renvoyer ce qui suit à la fin du fichier :

return (
  <div>
    <h2>With Docker</h2>
    <ul>
      {data.map((p: Person) => (
      <PersonComponent key={p.id} person={p} />
      ))}
    </ul>
  </div>
)

Les modifications seront prises en compte assez rapidement et apparaîtront sur le navigateur comme suit :

Next.js s'exécutant avec Docker et Docker compose localement

Bravo! Vous avez dockerisé avec succès un projet Next.js. Comme l'application a été dockerisée, vous pouvez l'exécuter sur n'importe quel service avec ou sans Kubernetes. Vous pouvez également essayer PostgreSQL avec Docker et Docker composer et le connecter à votre application Next.js.

Merci de nous avoir suivi, vous pouvez trouver tout le code de ce tutoriel dans ce dépôt GitHub . Pour le code spécifique au docker, veuillez vous référer à ce GitHub .

What is GEEK

Buddha Community

NBB: Ad-hoc CLJS Scripting on Node.js

Nbb

Not babashka. Node.js babashka!?

Ad-hoc CLJS scripting on Node.js.

Status

Experimental. Please report issues here.

Goals and features

Nbb's main goal is to make it easy to get started with ad hoc CLJS scripting on Node.js.

Additional goals and features are:

  • Fast startup without relying on a custom version of Node.js.
  • Small artifact (current size is around 1.2MB).
  • First class macros.
  • Support building small TUI apps using Reagent.
  • Complement babashka with libraries from the Node.js ecosystem.

Requirements

Nbb requires Node.js v12 or newer.

How does this tool work?

CLJS code is evaluated through SCI, the same interpreter that powers babashka. Because SCI works with advanced compilation, the bundle size, especially when combined with other dependencies, is smaller than what you get with self-hosted CLJS. That makes startup faster. The trade-off is that execution is less performant and that only a subset of CLJS is available (e.g. no deftype, yet).

Usage

Install nbb from NPM:

$ npm install nbb -g

Omit -g for a local install.

Try out an expression:

$ nbb -e '(+ 1 2 3)'
6

And then install some other NPM libraries to use in the script. E.g.:

$ npm install csv-parse shelljs zx

Create a script which uses the NPM libraries:

(ns script
  (:require ["csv-parse/lib/sync$default" :as csv-parse]
            ["fs" :as fs]
            ["path" :as path]
            ["shelljs$default" :as sh]
            ["term-size$default" :as term-size]
            ["zx$default" :as zx]
            ["zx$fs" :as zxfs]
            [nbb.core :refer [*file*]]))

(prn (path/resolve "."))

(prn (term-size))

(println (count (str (fs/readFileSync *file*))))

(prn (sh/ls "."))

(prn (csv-parse "foo,bar"))

(prn (zxfs/existsSync *file*))

(zx/$ #js ["ls"])

Call the script:

$ nbb script.cljs
"/private/tmp/test-script"
#js {:columns 216, :rows 47}
510
#js ["node_modules" "package-lock.json" "package.json" "script.cljs"]
#js [#js ["foo" "bar"]]
true
$ ls
node_modules
package-lock.json
package.json
script.cljs

Macros

Nbb has first class support for macros: you can define them right inside your .cljs file, like you are used to from JVM Clojure. Consider the plet macro to make working with promises more palatable:

(defmacro plet
  [bindings & body]
  (let [binding-pairs (reverse (partition 2 bindings))
        body (cons 'do body)]
    (reduce (fn [body [sym expr]]
              (let [expr (list '.resolve 'js/Promise expr)]
                (list '.then expr (list 'clojure.core/fn (vector sym)
                                        body))))
            body
            binding-pairs)))

Using this macro we can look async code more like sync code. Consider this puppeteer example:

(-> (.launch puppeteer)
      (.then (fn [browser]
               (-> (.newPage browser)
                   (.then (fn [page]
                            (-> (.goto page "https://clojure.org")
                                (.then #(.screenshot page #js{:path "screenshot.png"}))
                                (.catch #(js/console.log %))
                                (.then #(.close browser)))))))))

Using plet this becomes:

(plet [browser (.launch puppeteer)
       page (.newPage browser)
       _ (.goto page "https://clojure.org")
       _ (-> (.screenshot page #js{:path "screenshot.png"})
             (.catch #(js/console.log %)))]
      (.close browser))

See the puppeteer example for the full code.

Since v0.0.36, nbb includes promesa which is a library to deal with promises. The above plet macro is similar to promesa.core/let.

Startup time

$ time nbb -e '(+ 1 2 3)'
6
nbb -e '(+ 1 2 3)'   0.17s  user 0.02s system 109% cpu 0.168 total

The baseline startup time for a script is about 170ms seconds on my laptop. When invoked via npx this adds another 300ms or so, so for faster startup, either use a globally installed nbb or use $(npm bin)/nbb script.cljs to bypass npx.

Dependencies

NPM dependencies

Nbb does not depend on any NPM dependencies. All NPM libraries loaded by a script are resolved relative to that script. When using the Reagent module, React is resolved in the same way as any other NPM library.

Classpath

To load .cljs files from local paths or dependencies, you can use the --classpath argument. The current dir is added to the classpath automatically. So if there is a file foo/bar.cljs relative to your current dir, then you can load it via (:require [foo.bar :as fb]). Note that nbb uses the same naming conventions for namespaces and directories as other Clojure tools: foo-bar in the namespace name becomes foo_bar in the directory name.

To load dependencies from the Clojure ecosystem, you can use the Clojure CLI or babashka to download them and produce a classpath:

$ classpath="$(clojure -A:nbb -Spath -Sdeps '{:aliases {:nbb {:replace-deps {com.github.seancorfield/honeysql {:git/tag "v2.0.0-rc5" :git/sha "01c3a55"}}}}}')"

and then feed it to the --classpath argument:

$ nbb --classpath "$classpath" -e "(require '[honey.sql :as sql]) (sql/format {:select :foo :from :bar :where [:= :baz 2]})"
["SELECT foo FROM bar WHERE baz = ?" 2]

Currently nbb only reads from directories, not jar files, so you are encouraged to use git libs. Support for .jar files will be added later.

Current file

The name of the file that is currently being executed is available via nbb.core/*file* or on the metadata of vars:

(ns foo
  (:require [nbb.core :refer [*file*]]))

(prn *file*) ;; "/private/tmp/foo.cljs"

(defn f [])
(prn (:file (meta #'f))) ;; "/private/tmp/foo.cljs"

Reagent

Nbb includes reagent.core which will be lazily loaded when required. You can use this together with ink to create a TUI application:

$ npm install ink

ink-demo.cljs:

(ns ink-demo
  (:require ["ink" :refer [render Text]]
            [reagent.core :as r]))

(defonce state (r/atom 0))

(doseq [n (range 1 11)]
  (js/setTimeout #(swap! state inc) (* n 500)))

(defn hello []
  [:> Text {:color "green"} "Hello, world! " @state])

(render (r/as-element [hello]))

Promesa

Working with callbacks and promises can become tedious. Since nbb v0.0.36 the promesa.core namespace is included with the let and do! macros. An example:

(ns prom
  (:require [promesa.core :as p]))

(defn sleep [ms]
  (js/Promise.
   (fn [resolve _]
     (js/setTimeout resolve ms))))

(defn do-stuff
  []
  (p/do!
   (println "Doing stuff which takes a while")
   (sleep 1000)
   1))

(p/let [a (do-stuff)
        b (inc a)
        c (do-stuff)
        d (+ b c)]
  (prn d))
$ nbb prom.cljs
Doing stuff which takes a while
Doing stuff which takes a while
3

Also see API docs.

Js-interop

Since nbb v0.0.75 applied-science/js-interop is available:

(ns example
  (:require [applied-science.js-interop :as j]))

(def o (j/lit {:a 1 :b 2 :c {:d 1}}))

(prn (j/select-keys o [:a :b])) ;; #js {:a 1, :b 2}
(prn (j/get-in o [:c :d])) ;; 1

Most of this library is supported in nbb, except the following:

  • destructuring using :syms
  • property access using .-x notation. In nbb, you must use keywords.

See the example of what is currently supported.

Examples

See the examples directory for small examples.

Also check out these projects built with nbb:

API

See API documentation.

Migrating to shadow-cljs

See this gist on how to convert an nbb script or project to shadow-cljs.

Build

Prequisites:

  • babashka >= 0.4.0
  • Clojure CLI >= 1.10.3.933
  • Node.js 16.5.0 (lower version may work, but this is the one I used to build)

To build:

  • Clone and cd into this repo
  • bb release

Run bb tasks for more project-related tasks.

Download Details:
Author: borkdude
Download Link: Download The Source Code
Official Website: https://github.com/borkdude/nbb 
License: EPL-1.0

#node #javascript

Eva  Murphy

Eva Murphy

1625674200

Google analytics Setup with Next JS, React JS using Router Events - 14

In this video, we are going to implement Google Analytics to our Next JS application. Tracking page views of an application is very important.

Google analytics will allow us to track analytics information.

Frontend: https://github.com/amitavroy/video-reviews
API: https://github.com/amitavdevzone/video-review-api
App link: https://video-reviews.vercel.app

You can find me on:
Twitter: https://twitter.com/amitavroy7​
Discord: https://discord.gg/Em4nuvQk

#next js #js #react js #react #next #google analytics

Iliana  Welch

Iliana Welch

1595249460

Docker Explained: Docker Architecture | Docker Registries

Following the second video about Docker basics, in this video, I explain Docker architecture and explain the different building blocks of the docker engine; docker client, API, Docker Daemon. I also explain what a docker registry is and I finish the video with a demo explaining and illustrating how to use Docker hub

In this video lesson you will learn:

  • What is Docker Host
  • What is Docker Engine
  • Learn about Docker Architecture
  • Learn about Docker client and Docker Daemon
  • Docker Hub and Registries
  • Simple demo to understand using images from registries

#docker #docker hub #docker host #docker engine #docker architecture #api

Landen  Brown

Landen Brown

1626073860

Next.js on Fargate - Serverless Container Hosting with Docker and AWS Amplify

In this video we’ll start from scratch, creating a new Next.js app and then initializing a new Amplify project in the Next.js app directory. We’ll then configure a custom domain and deploy the Next.js app to Amazon ECS on AWS Fargate using the Amplify CLI using the custom domain.

Delete all infrastructure at any time by running “amplify delete”.

0:00 – Introduction
1:00 – Initializing the project
2:18 – Configuring the custom domain
4:33 – Enabling Fargate Hosting with the Amplify CLI
5:46 – Configuring the Dockerfile
7:27 – Testing the Docker image locally
8:32 – Deploying the app to Fargate using the Amplify CLI
12:00 – Conclusion

Dockerfile: https://gist.github.com/dabit3/6eb125dad05c1b1723bc44b6618e8ac4
Amplify Container docs: https://docs.amplify.aws/cli/usage/containers#hosting
Blog post: https://dev.to/dabit3/serverless-containers-with-next-js-aws-fargate-and-aws-amplify-17fe

#aws amplify #next.js #next #serverless container #docker

Authentication in Node.js - #3 Docker Compose for Development

When it comes to provisioning a local dev environment, you have at least 4 choices. One, you can offload all the heavy lifting to a 3rd-party service. For example, you could use Atlas or mLab for MongoDB, and Redis Labs for Redis. Just copy-paste the connection string, and you’re ready to go. Otherwise, you could also install mongodb-org and redis-server locally on your machine. This is the most intuitive, yet also most intrusive approach as it directly uses your OS to run both processes.

Another option is to install MongoDB and Redis in a VM such as Vagrant, which would eat up substantial resources to run a full-blown Linux OS alongside your host OS. This is probably an overkill when used for development. Lastly, you can provision both databases with Docker and (optionally) Docker Compose. We’ll go with the last option in this tutorial.

First, make sure to install docker and docker-compose on your machine. If you’re new to Docker, it will take some time to get used to, but once you’ve picked on a few simple commands, you can easily spin up light-weight containers for your everyday development. Docker Compose is useful when you need to manage multiple containers under a stack. Just keep in mind that it only works on a single host, and as such is only suited for local development. Don’t get too hung up on it, as you’ll probably use Kubernetes or Swarm in production anyway.

Sadly, MongoDB image doesn’t create an admin user for the initial database, although it’s a open issue on GitHub. To do so, you can map a shell script to the MongoDB entrypoint directory. This could be a JS file as well, except then you won’t have access to environment variables. The shell script needs to authenticate with MongoDB, create an admin user, and grant them write permissions on the initial database.

One issue that you will run into on Linux (either locally during development or in production after deployment) is directory ownership of the data volume. When you map the data directory from a MongoDB container to a local file-system directory, its ownership changes recursively to an elevated user, such as root. You can find this problem described in these GitHub issues.

To fix this on Linux, before running any docker-compose command (not only up, but also stop, down, etc.), you need to (1) explicitly export UID in the current shell, and (2) make the volume directory (with -p if it already exists). This way data directory is owned by the currently logged-in user (i.e. you) and not an elevated user (i.e. root). Otherwise, its ownership will silently change to root, and you may run into critical errors when re-booting the container stack.

#node.js #docker #linux #docker compose