Find the tutorials

the key process is extrudeMesh, which extrudes one patch for a certain distance after the 3D mesh is generated.
So look for the extrudeMeshDict files in the $FOAM_TUTORIALS folder using this command

find $FOAM_TUTORIALS  -name extrudeMeshDict

The extrudeMeshDict looks like this:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      extrudeProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

constructFrom patch;
sourceCase "$FOAM_CASE";  //Use "." to extrude the current case in situ

sourcePatches (back);   
exposedPatchName front;  //Note that here no brackets are needed
 
extrudeModel  plane;
thickness     0.1;

flipNormals false;
mergeFaces false;

Generate the background mesh, run snappyHexMesh and do the extrusion using the following commands.

blockMesh
snappyHexMesh -overwrite
extrudeMesh

Or in parallel

blockMesh
decomposePar
foamJob -s -p snappyHexMesh -parallel -overwrite
reconstructParMesh -constant #include the constant dir in the times list
rm -rf 1 2 3
extrudeMesh

Pitfalls

Fatal error in parallel 2D hex-meshing

When setting up the 2D simulation cases, the boundary condition of frontAndBack patches should be set to empty to prevent OpenFOAM from doing calculations in the third dimension. Similarly, an empty boundary type can tell snappyHexMesh don't bother to mesh in the perpendicular direction. This works just fine when you mesh on a serial processor, but when one tries to do the same meshing process in parallel, snappyHexMesh would give the following complaints and lead to a fatal error.

Scaling iteration 0
Moving mesh using displacement scaling : min:1  max:1
Correcting 2-D mesh motion--> FOAM Warning : 
    From function void Foam::motionSmootherAlgo::modifyMotionPoints(Foam::pointField&) const
    in file motionSmoother/motionSmootherAlgo.C at line 657
    2D mesh-motion probably not correct in parallel
--> FOAM Warning : 
    From function void Foam::twoDPointCorrector::calcAddressing() const
    in file twoDPointCorrector/twoDPointCorrector.C at line 160
    The number of points in the mesh is not equal to twice the number of edges normal to the plane - this may be OK only for wedge geometries.
    Please check the geometry or adjust the orthogonality tolerance.

...

--> FOAM FATAL ERROR: 
[2] face 198 area does not match neighbour by 0.0076471% -- possible face ordering problem.

From the error message, we can see that it is quite sure that snappyHexMesh successfully recognises the background mesh as a 2D one, so far so good. But the message also tells us that it is "probably not correct in parallel" to do 2D meshing, which is quite bothering.
Luckily, we can use the symmetryPlane BC when defining the type of the frontAndBack patch in blockMeshDict, and it works fine with snappyHexMesh in parallel. But you should change the patch type back to empty when the meshing is complete since a symmetryPlane patch cannot hold the empty boundary condition.

Unwanted over-refinement on edges

Sometimes one may find that there is an unwanted refinement on some edges where he did not assign any levels of surface refinement(the 2D edge used to be a 3D face before extruding).
Take a look at the 3D mesh before extruding; one may find that the refinement comes from the feature edges. So try to bypass the feature edge refinement process by, e.g. having the frontAndBack planes of the background mesh cut through the STL model instead of coplane the front/back faces to totally exclude these edges or just turn off the feature edge refinement process.